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

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

From: John Siracusa
Subject: Re: Annouce: DBIx::Class, a.k.a "taking the easy way out"
Date: 22:02 on 25 Jul 2005
On 7/25/05, Matt S Trout <cdbi-talk@xxxxx.xx.xx> wrote:
>> Project 1:
>>
>>> start by looking at Class::DBI, working out which are the core features, and
>>> then build something nice, clean and extensible that provides those and the
>>> means to add extra features [...]
>>
>> Many incarnations of Project 1 already exist on CPAN, so it may be easier to
>> simply build Project 2 on top of them.
> 
> "many incarnations" ? I call bullshit, given you haven't provided a single
> example.

What I meant was that there are a lot of other "Class::DBI-like modules" on
CPAN upon which a Class::DBI compatibility layer might be built: Alzabo,
Tangram, etc.  Whether you find them suitable depends on your definition of
"clean and extensible," I suppose (and on what's on your list of "core
features.")

>> I'm not sure where this idea got started that sticking things onto @ISA is a
>> suitable "plug-in" architecture.  Unless it's very tightly controlled (e.g.,
>> a single, central authority that ensures that all "mix-in classes"--a more
>> appropriate name than "plug-ins"--work together and/or declare their
>> incompatibilities), it's a road to tears.
> 
> Yes. NEXT-based plugins require you, the plug-in writer, to be careful for
> them to be robust.
> 
> Due to their tendency to stomp on each other, export-based plugins require
> the end-user to be careful.
> 
> Guess which one I'm voting for?

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

>> Extensibility through modular, replaceable components is the traditional
>> meaning of "plug-ins."  Inheritance/subclassing is something else entirely.
> 
> I could achieve exactly the same means by putting trigger points *everywhere*.
> 
> Well, not exactly - it wouldn't work for some odd cases, it'd be massively
> inefficient, and the code would be hideous.

I agree.
 
> Or we'd end up with the godawful-horrific-clawing-your-eyes-out-in-pain mess
> that is the current Class::DBI plugin landscape [...] Now *that* is a road to
> tears.

I agree.

I'm not suggesting that you not use NEXT or subclassing as you build your
modules.  What I am suggesting is that "NEXT-enabled subclasses" do not make
for an appropriate public "plug-in" architecture.

-John

(message missing)

Re: Annouce: DBIx::Class, a.k.a "taking the easy way out"
John Siracusa 22:02 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