John, for what it's worth, I agree with you.
Ties may be a nifty Perl feature, and DBI may be implemented as a tied hash, but that's something that I don't think a user should have to know.
Perhaps this is cruft from the Perl 4 days where there were no objects.
I would be very happy for *everything* to be accessible by a method call. Its a lot more consistent, and I believe it leads to cleaner code, and as you say, it avoids some kinds of silent errors.
And of course, adding these methods doesn't have to break the old interface, so no worries there.
-- Darren Duncan
At 7:56 PM -0400 8/2/04, John Siracusa wrote:
I meant to post this earlier, but here's my humble feature request for DBI 2.0 (or beyond):
The tied(?) hash interfaces in DBI grate on me. You know, $dbh->{'RaiseError'}, $sth->{'Active'}, and all that jazz. I'd sorely like to see these change to normal methods with more Perl-ish names:
$dbh->raise_error(0); $sth->active; $sth->ix_cursor_with_hold(1);
Reasons I suspect for the other interface:
* More efficient (maybe) * Easier to local()ize attributes * Easier to "no-op" on custom attributes (e.g. ix_CursorWithHold) (...or a possible bug, depending on how you look at it; see below.) * Youthful indiscretions of DBI 1.0 and earlier ;)
Reasons I like a regular method call interface better:
* More efficient (maybe) * Easier to subclass * Less likely for a typo to cause a "silent" bug * More perl-ish naming * Fewer quotes and curly braces :)
Maybe this is DBI 3.0 I'm talking about, or maybe I'll forever be doomed to implement DBI wrapper after DBI wrapper, but I thought I'd give it a shot :)
-John
