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: 23:57 on 26 Jul 2005
On Wed, Jul 27, 2005 at 12:14:50AM +0100, Tony Bowden wrote:
> > > All the plugins need to know is what they can do with the searcher,
> > > based on on what's in its API. 
> > What happens if each one needs to interrupt the search process at a different
> > stage, and some need to interpose themselves to figure out the results?
> 
> You've just changed the focus of the discussion quite dramatically.
> 
> The code posted was about generating the search, not in executing it.

But this is exactly my point. If changing from talking about interrupting
one part of a feature to another part of it "changes the focus of the
discussion quite dramatically", the API is too limited.

Providing delegation interfaces seems to me a lot of similar specific
solutions (one per delegation) rather than simply providing a general
solution to what you're doing. The easy things aren't as easy that way
but the hard things are possible for values of hard that in a delegation
environment would be simply impossible.
 
> Can you give some new examples of what sorts of things you're talking
> about here?
> 
> > e.g. you have Pre, Wrap1, Wrap2, Post
> > Your calling order goes
> > Pre { }
> > Wrap1 {
> >   Wrap2 {
> >     Original
> >   }
> > }
> > Post { }
> > By the time you've added enough delegation hooks to make the whole thing
> > work, I'd expect you'd end up with an API that's overcomplicated, higher
> > overhead than my approach and there's probably still a fairly good chance
> > of a plugin author breaking stuff if they're not careful.
> 
> Straw man.
> 
> No-one has postulated the code you're suggesting, so tearing that down
> is no real value.

No-one has postulated it? So because nobody's directly suggested something
that requires a particular combination of actions, it doesn't matter if the
implementation can support it?

Delegation allows you to provide for every overloading requirement you can
think of. Mixins (which is effectively what my MI and NEXT use works as)
allow you to provide for a lot of the ones you can't as well, without the
person who does having to get a patch merged back into the original module.

I fully expect conventions to develop about how mixins for certain tasks
are written but I don't see any reason to dictate those conventions; I'd
much rather let them evolve naturally as people try stuff and see what
works.

        -- 
             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 23:57 on 26 Jul 2005

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