Re: Annouce: DBIx::Class, a.k.a "taking the easy way out"

[prev] [thread] [next] [Date index for 2005/07/26]

From: Michael G Schwern
Subject: Re: Annouce: DBIx::Class, a.k.a "taking the easy way out"
Date: 18:15 on 26 Jul 2005
On Tue, Jul 26, 2005 at 05:59:46PM +0100, Matt S Trout wrote:
> > There's the brittleness of relying on inheritance order.
> 
> Yes. Yes there is. Apart from having something that can check for obvious
> stupidity caused by your inheritance order, there's not much I can do about
> it apart from tell people "Be Careful!".

Well, you could not use multiple inheritance. ;)


> > If I want to override, say, your SQL abstraction behavior... well I can't.
> > You've hard coded this behavior via inheritance.  If you were, instead, to
> > delegate this behavior to an SQL abstraction object and call methods on that
> > object you now allow anyone to write an SQL abstraction class with a similar
> > interface as yours and plop their object in place of yours.  Its flexible.
> > It avoids having to hack in a plug-in architecture later.
> 
> Now I think you're missing the point :)
> 
> DBIx::Class::Core contains
> 
> use base qw/DBIx::Class::Relationship
>             DBIx::Class::SQL::OrderBy
>             DBIx::Class::SQL::Abstract
>             DBIx::Class::PK
>             DBIx::Class::Table
>             DBIx::Class::SQL
>             DBIx::Class::DB
>             DBIx::Class::AccessorGroup/;
> 
> It isn't really a module in its own right, just a "standard recipe" for
> composing a set of DBIx::Class components for use in an application. 

This I don't disagree with, that your module should act like an extension... 
eating your own dog food.  That's good.  I just don't like the liver and 
giblets flavor.


> If
> you want to do something different, all you have to provide is a class
> called My::DBIC::SQL::Abstract which includes a suitable sub _cond_resolve,
> and then create your own recipe -

Red flag right there.  Advertising overriding of _private methods bluring
encapsulation.


> package My::DBIx::Class::Core;
> 
> use base qw/DBIx::Class::Relationship
>             My::DBIC::SQL::Abstract
>             DBIx::Class::PK
>             DBIx::Class::Table
>             DBIx::Class::SQL
>             DBIx::Class::DB
>             DBIx::Class::AccessorGroup/;
> 
> (note I've removed the OrderBy plugin as well because SQL::Abstract handles
> it)
>
> Whether you consider this "recipe" style good or not is a matter of taste.

Its not a matter of taste, I can point to specific problems.  Not only do 
users have to know specific details of inheritance order inside DBIx::Class 
but they have to repeat it in their subclass.  Both encapsulation and DRY 
are violated.

What happens when you want to add in another subclass to DBIx::Class?
All the extension code that copied your inheritance tree now cannot take
advantage and possibly breaks.

These are "down the road" problems but I've been down this road.


        -- 
        Michael G Schwern     schwern@xxxxx.xxx     http://www.pobox.com/~schwern
You are wicked and wrong to have broken inside and peeked at the
implementation and then relied upon it.
	-- tchrist in <31832.969261130@chthon>

(message missing)

Re: Annouce: DBIx::Class, a.k.a "taking the easy way out"
Michael G Schwern 18:15 on 26 Jul 2005

Delegation vs Hooks (was: Annouce: DBIx::Class, a.k.a "taking the easy way out")
=?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?= 23:27 on 26 Jul 2005

Generated at 16:36 on 28 Jul 2005 by mariachi v0.52