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: 22:20 on 26 Jul 2005
On Tue, Jul 26, 2005 at 11:11:46PM +0100, Matt S Trout wrote:
> Plus, what if you want to plug-and-play with layers of search generation?
> e.g.
> 
> My::Search does the WHERE condition
> My::OrderBy adds the ORDER BY
> My::Limit add the LIMIT clause
> 
> How can you arrange to drop in and replace any of the three of these without
> something, somewhere, having explicit knowledge of what to replace where?

You make a query object that examines the query and does the appropriate 
multiplexing inside itself and drop it in place.  If you notice a lot of
people doing this then you make life easier for your developers by providing 
optional delegate spots for WHERE, ORDER BY and LIMIT objects.

How would you do this with multiple inheritance?


> The problem with what you're talking about is that it ties you down to
> specific points to plug in to things. This is fantastic in terms of meeting
> the appropriate CS theory guidelines, but in practice you *always* end up
> needing something it didn't - hence why many Class::DBI plugins override all
> sorts of private methods (Sweet is terrible for this but I had no other
> choice). So instead, I'm going to let people override anything however they
> like and once a bunch of different approaches have been tried we can sit
> down and recommend the best one.

CDBI is a bad example because, well, its not particularly well designed.  And
it uses MI... so maybe its a perfect example. :)

But with delegation, especially in a system like you're putting together
where everything is delegated/inherited, you have total control over the
implementation.  You can choose to delegate to a subclass of the normal
delegates or you can rewrite the whole thing and just keep the same
interface.  You have the total control WITHOUT having to stab at private
methods and violate privacy.

The critical difference being your system talks to a known, public, defined
API.  Internal changes to either DBIx::Class or the extensions don't cause
problems because some extension author is hijacking a private method.

And if push comes to shove there's nothing stopping you from making a
subclass of *any* part of the system, the delegates or the delegator, and
overriding private methods.


        -- 
        Michael G Schwern     schwern@xxxxx.xxx     http://www.pobox.com/~schwern
ROCKS FALL! EVERYONE DIES!
	http://www.somethingpositive.net/sp05032002.shtml

(message missing)

Re: Annouce: DBIx::Class, a.k.a "taking the easy way out"
Michael G Schwern 22:20 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