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

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

From: Sebastian Riedel
Subject: Re: Annouce: DBIx::Class, a.k.a "taking the easy way out"
Date: 01:41 on 27 Jul 2005
Am 27.07.2005 um 01:29 schrieb Cees Hek:

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

Indeed, but there are enough plug-ins using NEXT to add trigger
points and stuff...just easy and beautiful.
I'm sure i'll get flamed for this, but for me NEXT is AOP on steroids.

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

Exactly what we though a few weeks ago, we already have a working
branch using delegation for engine and dispatcher. (will be merged
with trunk soon) :)

http://dev.catalyst.perl.org/repos/Catalyst/branches/refactored/

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

Agreed, use the right tool for the right job, but don't just outlaw
MI because you had a bad experience somewhen back in stoneage. ;)


P.S.: Third try, since it seems "someone" unsubscribed be from the  
list for whatever reason. :/


--
sebastian

(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"
Sebastian Riedel 01:41 on 27 Jul 2005

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