On Apr 21, 2010, at 9:12 PM, Kate Yoak wrote:
Personally I would just have the builder in _orm_table figure this
all out? or add an instance level 'orm_table' attribute so that I
could vary it on a per-instance basis if the need ever arose.
Thanks, Stevan. My intent was to use class data for class methods
(where you don't intend to have an instance). Your response made me
wonder. Should one really have class methods? I am caught up in
Rose::DB::Object's argument that if $product should exhibit the
behaviors expected of a product record, $product->list is
inappropriate. They go as far as to create a separate namespace
for multi-object queries. So it's ok to say $product(name =>
'kate'); $product->save; You have to say Product::Manager-
>get_products(name => 'kate') when you want to search.
Now that I am looking at it more closely, I am realizing that
perhaps, it's this decision that's having me just through hoops in
the first place! I am disliking the idea of needing to know the
Product::Manager namespace and writing code to avoid it. Modifying
Rose::DB::Object to drop this non-oo approach will make everything
cleaner.
Yes, see it is this kind of thing that I don't like about class data/
methods. Since the primary responsibility of a class is to construct
instances it is all to tempting to think "I can make a class method
that returns a set of instances", when what you really want is to
create an instance of a collection class. This is one of the things
that DBIC really gets right IMO, the whole idea of the resultset.
As for hiding the existence of the ::Manager class, a simple factory
will hide that. Again, this is where DBIx::Class gets it right.
my @products = $schema->resultset('Product')->all;
That just makes sense IMO, and I never have to know that there is a
Product 'Result' class and a Product 'Resultset' class under the hood
(unless I want to).
- Stevan
