DBI's OO implementation

Hi, Tim,

I believe that the time for asking this is appropriate, because you
seem to be in a phase of basic considerations: Are you planning that
DBI 2 will still have what I call its own OO implementation?

In case that my term doesn't clearly tell what I mean: I am referring
to the way, how DBI sits both on top and below the driver, database,
and statement handles. Or, in other words, I am talking about the fact
that what the driver returns as a database handle (for example, an
instance of DBD::mysql) isn't, what the driver user actually sees (but
an instance of ... heck, what is it, I do not exactly remember, ...
DBI::db? DBI::_::db?, whatever.

I remember, when we had a discussion on the subject that speed was the
reason for designing things like this. I never did any measurements
and believe that you did, so possibly the desicions was right. But
that decision was taken in or around 1996 and for Perl 5. Besides, I
can hardly imagine that the difference was more than some 5 or 6
percent: Usually the communication with the database is the limiting
factor, because I can hardly imagine that the DBI architecture of
stacked handles needs less memory than a basic system of subclasses
(which internally is in place anyways).

I am asking, because I do see a dark side too: I always found the
system less than obvious , diff=EDcult to handle, and a source of *very*
subtle reasons, why things wheren't working as expected. I never
worked on the DBI itself, so I cannot tell for sure, but if the work
was more difficult for the driver author, then it is reasonable to
guess that the same holds true for the DBI author.

Thus, if possible: Use simple Perl inheritance from now, use the basic
OO model, and nothing else.

Jochen

--=20
Having experienced 7 years of labour/green government, I now know the
reason, why a conservative government is good for the economy: The
economy's unable to imagine anything else ...