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

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

From: Michael G Schwern
Subject: Re: Annouce: DBIx::Class, a.k.a "taking the easy way out"
Date: 22:12 on 25 Jul 2005
On Mon, Jul 25, 2005 at 06:02:43PM -0400, John Siracusa wrote:
> "Plug-ins" are held to a different standard, IMO.  The developer of a
> plug-in should just have to know an API.  Once the developer has to start
> worrying about what *other* "plug-ins" are doing, the modularity of the
> system has been compromised.
> 
> Using NEXT is a great way to build a subclass and manage multiple
> inheritence, but the necessary interactions that result from subclassing
> and MI are well beyond what a "plug-in" author should have to worry about.
> 
> This may all sound like semantics, but I believe there's an important
> distinction in both design and purpose.  The idea that arbitrary subclasses
> can be mixed and matched as if they were as independent as proper "plug-ins"
> (e.g., QuickTime codec plug-ins) is a dangerous one.  Barring any central
> authority to vet all such subclasses and certify how they can be combined
> with all other existing subclasses without breaking anything, I believe the
> name "plug-in" is not applicable.

If I understand how NEXT is going to be used here [1], especially in relation 
to mixins stomping on each other's mixed in methods (ie. Plugin A and Plugin B
both want to mixin method foo() and the user uses both), it would seem using
NEXT would just solve one problem and create a related one.  So now if two
plugins want to alter the behavior of the same method NEXT allows for them
both to be called.  Well this creates a new class of problems: clashing
behaviors.  Plugins A and B want to change how transactions work.  If you
run them both... who knows what's going to happen?  Are their behaviors
mutually compatible?  Are they going to stomp all over each other inside the
object?

I really don't know how real plugin architectures deal with this sort of 
problem, but in the meantime I'd go with one plugin can override one method
and that's it.  Anything more is an error.


[1] And I probably don't.

        -- 
        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 22:12 on 25 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:37 on 28 Jul 2005 by mariachi v0.52