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

[John Siracusa]

On Mon, 25 Jul 2005 Matt S Trout <cdbi-talk at trout.me.uk> 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.

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.

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

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

Project 2:

> a full Class::DBI compat layer

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

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

Extensibility through modular, replaceable components is the traditional
meaning of "plug-ins."  Inheritance/subclassing is something else entirely.

-John