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

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

From: Matt S Trout
Subject: Re: Annouce: DBIx::Class, a.k.a "taking the easy way out"
Date: 00:02 on 27 Jul 2005
On Tue, Jul 26, 2005 at 07:29:51PM -0400, Cees Hek wrote:
> On 7/26/05, Sebastian Riedel <sri@xxxx.xx> wrote:
> > 
> > I said before that we have 80+ plugins using multiple inheritance and
> > all work fine together, stuff that would never be possible with
> > "pure" delegation.
> 
> But a lot of the plugins in Catalyst that 'won't work with delegation'
> don't actually change the behaviour of Catalyst.  They add extra
> functionality (for example, sessions or form validation).  In these
> cases you aren't using Multiple Inheritance in order to override
> certain functionality, you are using it as a convenient way to add
> extra helper methods to Catalyst.  This is more of a decorator or
> mixin pattern.  And you are right that delegation would be difficult
> to use for these.  This also won't show many of the problems of MI
> since these types of plugins generally use unique method names.
> 
> However the Catalyst::Engine series of modules would be a good example
> where you could use delegation instead of MI.  You have a defined set
> of methods that each Engine module should provide in order to function
> correctly.  Here you are changing the way a certain (clearly defined)
> part of Catalyst behaves.

Funnily enough, doing that for both Engine and Dispatcher is In The Works.

See http://dev.catalyst.perl.org/repos/Catalyst/branches/refactored for
the current progress.
 
> > Btw. for me, this was never a delegation vs. multiple inheritance
> > war, i use both, for the right task.
> 
> So perhaps DBIx::Class could use delegation for all clearly defined
> 'tasks' that need to be performed (SQL generation, iterators,
> relationships, etc...), but MI can be used for extending functionality
> that can not easily be plugged in to the existing infrastructure (I
> prefer mixins instead of MI for extending functionality but that has
> it's own set of problems too).

To be honest, in the case of pure extension stuff they are pretty much mixins,
just implemented via MI so you don't risk the namespace clashes of import-style
mixins.

The problem comes when you need to override existing functionality in the
process of adding more; that's fine the first time - add your methods in
the mixin and set the delegate to use yours, but then what happens when a
second module needs to do the same thing or your user class wants to provide
its own delegate for the task?

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

(message missing)

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

Re: Annouce: DBIx::Class, a.k.a "taking the easy way out"
Matt S Trout 00:02 on 27 Jul 2005

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