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

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

From: Matt S Trout
Subject: Re: Annouce: DBIx::Class, a.k.a "taking the easy way out"
Date: 20:55 on 25 Jul 2005
On Mon, Jul 25, 2005 at 11:32:48AM -0400, John Siracusa wrote:
> On Mon, 25 Jul 2005 Matt S Trout <cdbi-talk@xxxxx.xx.xx> wrote:
> > After a week of giving myself a headache, I understood why Tony isn't already
> > halfway through - it's *hard*, especially if you're going to maintain the API
> > and the stability that so many Class::DBI users rely on. [...]
> >
> > Comments, suggestions, questions and flames welcome.
> 
> I'm not sure how much bang you'll get for your buck if, in your new module,
> you decide to preserve all the things that make cleanly extending Class::DBI
> difficult.  As you point out, the API is one of those things.

I'm not. I specifically said I'm not. I've thrown most of it away, but just
as it is possible to implement complex languages easily in Lisp a complex
API like Class::DBI can still be implemented easily enough given the right
core to work from.

> But beyond the API, if you decide to imitate the basic design of Class::DBI
> (i.e., a single class that's a database handle, a representation of a single
> row, and a means to retrieve multiple rows) I suspect you'll eventually run
> into the same issues as Class::DBI has.

I haven't. I already said I wouldn't.

There's a standard aggregation of classes that will probably in the end be
called DBIx::Class::TableAndDB or something, which will be cdbi-ish. I'm
already experimenting with having one class that ISA DBIx::Class::DB to
be a container for the dbh, another class that ISA DBIx::Class::Table to
handle the table definition, and then combining them together in a subclass
that's dbh + table specific.

Those of you wanting to run lots of instances of the sane mod_perl app on
different databases might find the above concept interesting.

> Splitting your idea into two separate projects may help you avoid potential
> disaster.

Reading the code before posting a reply to a call for comments on said code
has a similar effect.
 
> 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

Yes, this is currently DBIx::Class::Core.

> Project 2:
> 
> > a full Class::DBI compat layer

Yep. It's called DBIx::Class::CDBICompat.

> Many incarnations of Project 1 already exist on CPAN, so it may be easier to
> simply build Project 2 on top of them.  But speaking of "clean and
> extensible"...

"many incarnations" ? I call bullshit, given you haven't provided a single
example.

> > The model I've chosen is total pluggability via NEXT
> 
> 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?

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

And I'd also point out that the "subclasses" all talk using NEXT. Which turns
it more into an object composition thing - the perl method dispatcher has
been perverted far worse for far less gain before now. You might like to read
up at ftp://parcftp.xerox.com/ if they haven't turned it off yet - some of the
OO research stuff, early LOOPS/PCL/CLOS bits and pieces and the minimal object
systems in scheme will help enlighten you to a world of OO concepts that
you appear not to have come across before.

Or we'd end up with the godawful-horrific-clawing-your-eyes-out-in-pain mess
that is the current Class::DBI plugin landscape, where your OWN BLOODY
NAMESPACE suddenly sprouts all these methods that weren't there a minute
ago. I often define an empty subclass of a plugin loading class just to put
my own methods in so I don't have to worry about that sort of idiocy.

Now *that* is a road to tears.

        -- 
             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 20:55 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