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

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

From: Matt S Trout
Subject: Re: Annouce: DBIx::Class, a.k.a "taking the easy way out"
Date: 18:58 on 26 Jul 2005
On Tue, Jul 26, 2005 at 11:15:34AM -0700, Michael G Schwern wrote:
> > > 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.

Well that's because the final stage where what's food and what's by-product
is filtered out doesn't exist yet. I'm still working that out as I go along.

But I'm glad you agree with me on something :)
 
> > 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.

Yes, it's blurring encapsulation. At some point I think I'll probably provide
some sort of convention (maybe _ versus __) to indicate "internal but
overridable" versus "implementation detail", but I'm still evolving which
is which so that'll come later, along with nextalyzer support to warn you
when you override implementation detail methods.

> 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.

Correct for the moment, but I think it should be possible to have a
requires/provides system to deal with this and at least flag up problems,
if not make a good stab at auto-resolving the correct order.
 
> 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.
 
use DBIx::Class::AutoIsa qw/::Core -except -replace ::SQL::Abstract ::SQL::OrderBy -with My::DBIC::SQL::Abstract/;

Or something along those lines might make things easier.

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

I've done quite a bit of work using Maypole, and have seen MI-related
breakages of various forms first-hand in the process.

I think I can still make this work. The problems you mention above are
very real, but I think I can provide at least partial solutions to most if
not all of them via tooling and introspection.

The use of NEXT and MI is, realistically, a hack - but even with the
additional effort I'll need to make to ensure it doesn't turn into a
minefield for users and developers alike, I think it's going to be less of
a hack than any other way I can think of to achieve the flexibility I want.

I must say I'm really enjoying this conversation; you aren't dissuading me
any from the approach, but you're bringing the problems I'm going to have to
solve in order to make the approach usable into far better focus. Thank you.

        -- 
             Matt S Trout           Website: http://www.shadowcatsystems.co.uk
  Technical Director        E-mail:  mst (at) shadowcatsystems.co.uk
Shadowcat Systems Ltd.

(message missing)

Re: Annouce: DBIx::Class, a.k.a "taking the easy way out"
Matt S Trout 18:58 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