On Aug 4, 2004, at 11:15 AM, John Siracusa wrote:
There are better ways to implement encapsulation and extensibility
than tied hashes. They're called "objects" and "methods" :) If ties were
sufficient and "just as good", then Perl 5 (and 6) would have no need for
proper objects and methods.
and:
DBI's existing interfaces makes it much more difficult and fidgety to
subclass things easily, or even aggregate the component parts.
There's a lot of "magic" lurking behing all those innocent looking
$sth and $dbh variables. It's not a particularly friendly or
extensible interface, and there's definitely a big mismatch with the
direction of Perl 6 style interfaces. Even if it has to wait for DBI
3 or 4, the days of "magical" assignments to $h->{'JavaYukFoo'} are
numbered...
There is one critical point that nobody addressed, and I think the only person to address it properly is Tim himself. If and until he does it, all this is pure discussion about eye-candy. It would take someone a bored afternoon to wrap all the DBI interface into a "post-wild-west" logical (to the wrapper-writer), clean (to the wrapper-writer), "modern" module.
The critical point is of course Speed. With a capital S.
I have no idea what compromises Tim made to get both extreme speeds and a well-working interface. Maybe nothing was done and the interface is a relic of the old days. Maybe a lot was done that was necessary, like the tied hashes and magic in the SVs. All I can say is that I have used DBI and its performance is stellar, and I have looked at the DBI code and its complexity is astounding. No good coder would want to create complexity for its own sake, while aiming (and achieving) performance.
Therefore, I am inclined to believe that some of the non-conformance to current "standards" in DBI must be due to the need for speed.
Create whatever wrappers you want, make accessor functions, subclass DBI so that a subclass of your subclass is done in a "standard" way if you wish. It's not hard to do, and it's not hard to maintain. Just remember that the more abstraction you create, the slower you are.
I myself will happily stay with what we have, thank you very much.
H
