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: 17:15 on 26 Jul 2005
On Mon, Jul 25, 2005 at 09:15:05PM -0400, John Siracusa wrote:
> On 7/25/05 6:12 PM, Michael G Schwern wrote:
> > I really don't know how real plugin architectures deal with this sort of
> > problem [...]
> 
> Ideally, plug-ins have a single, well-defined interface.  For example,
> imagine an image viewer that supports plug-ins for image formats.  The
> plug-in API would say something like, "We feed you a file path, you return a
> buffer full of 16-bit-per-component color values in ARGB format."
> 
> If you use something like subclassing or multiple inheritance as your
> "plug-in" mechanism, it's almost impossible to define and enforce a simple
> API and set of plug-in rules (since, by their nature, subclasses can
> override/augment "anything.")  And as Michael Schwern has been elaborating
> on in recent posts, it also makes conflict resolution and cross-plug-in
> interference and incompatibilities very, very difficult to manage and
> predict, especially in the long term.

Actually, I agree entirely about specific-purpose plugins. However, that's
not what I'm trying to achieve here. Perhaps I should have said "MI and
NEXT for extensions" instead. The thing is, adding such a simple plugin
API is easy within DBIx::Class - see ::CDBICompat::Triggers which allows
us to pass the CDBI triggers.t. However, every check for a plugin adds
overhead, so I want to make such specific-purpose plugin APIs pluggable
themselves so if people don't want a plugin to do such a thing, they
don't have to.

I would also point out that even within the current system it's possible
to write plugins that are guaranteed to play nice if you're careful - for
example DBIx::Class::PK::Auto just calls an _last_insert_id method. Any
database-specific plugin to get this information should provide that method
and only that method.

The reason plugin APIs bloat is because people want to be able to overload
more stuff than the original API author expected. I'm not sure what people
will want to overload from the front-end yet, so rather than guessing I'm
trying to make it easy for them to add single-purpose plugin APIs themselves
in a reasonably clean fashion.

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

(message missing)

Re: Annouce: DBIx::Class, a.k.a "taking the easy way out"
Matt S Trout 17:15 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:37 on 28 Jul 2005 by mariachi v0.52