Re: DBI 2.0 interface change request
On 6 Aug 2004, at 08:53, Jochen Wiedmann wrote: Matt Sergeant wrote: And easier to implement in C. I never found any difficulties in the methods handling properties? It's the difference between implementing a function called xyz and doing a string comparison for xyz. It's easier to make it more modular if you have separate functions, compared to a big honking dispatch table. It's minor quibbles though. Matt.
Re: DBI 2.0 interface change request
On 3 Aug 2004, at 14:41, John Siracusa wrote: On Tue, 03 Aug 2004 09:35:25 +0200, Jochen Wiedmann That gains absolutely *no* functionality It's a heck of a lot easier to subclass... And easier to implement in C. Matt.
Re: DBI 2.0 interface change request
Matt Sergeant wrote: And easier to implement in C. I never found any difficulties in the methods handling properties? Jochen
Re: DBI 2.0 interface change request
At 10:45 PM -0700 8/3/04, Dean Arnold wrote: As for me, give me a tie, and let declaration guide me Let me ask you this. Can you as a user access *all* DBI features and functionality easily through just the tied interface? For example, is there a way you can run prepare() by just setting or reading a hash value? If not, then the use of methods or functions *is already required* by DBI. Just look at the SYNOPSIS documentation. As near as I can tell, most functionality is method-only, with a few miscellaneous extras being tied only. My impression of John Siracusa's request was for interface uniformity, to take those last few tied hold-outs and make method-form equivalents for them. This sort of thing is not supposed to be the domain of a wrapper module. -- Darren Duncan P.S. This has nothing to do with the merits of SQL; that's a separate matter.
Re: DBI 2.0 interface change request
Darren Duncan wrote:
Just look at the SYNOPSIS documentation. As near as
I can tell, most functionality is method-only, with a few miscellaneous
extras being tied only.
Another way to look at it is that DBI is made up of handles which have
the very important property that the behaviour of a handle's methods can
be modified by setting its attributes independent of other sorts of
parameters passed to the method. It is not a miscellaneous extra that
\%attrs is a parameter to virtually every method in the DBI or that
passing \%attrs does a fundamentally different thing than passing $dsn,
or $sql or $value. This important feature will be expanded in v2.x as
things like $dbh-connect() and $sth-prepare() and per-statement-handle
-attributes are introduced.
If you change $dbh-{RaiseError}=1 to $dbh-raise_error(1), what is it
you are proposing for DBI-connect( ..., {RaiseError=1, PrintError=0}
)? Handle attributes are a series of name/value pairs. What more
natural way is there in Perl to deal with name/value pairs than a hash?
And since hashes can be tied to provide privacy and encapsulation,
what rule does it break to use them other than the rule that objects
have round things at the end of their arrows rather than squiggly things?
--
Jeff
Re: DBI 2.0 interface change request
Jeff Zucker sent the following bits through the ether:
If you change $dbh-{RaiseError}=1 to $dbh-raise_error(1), what is it
you are proposing for DBI-connect( ..., {RaiseError=1, PrintError=0}
)?
Of course, if you happen to not like tied hashes as an API, it's
entirely possible to write an OO wrapper around them. DBIx::Object,
anyone?
Leon
--
Leon Brocard.http://www.astray.com/
scribot.http://www.scribot.com/
... Genetic scientists wear designer genes
Re: DBI 2.0 interface change request
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
Re: DBI 2.0 interface change request
On Tue, Aug 03, 2004 at 10:37:57AM +0100, Tim Bunce wrote: Meanwhile, now isn't the time to be getting into debates about such future details. Enough already, please. More heat than light is being generated. The DBI interface is not going to change significantly anytime soon. If anyone wants a different interface they're very welcome to create their own. But not here on this list. Thank you. Tim.
Re: DBI 2.0 interface change request
Darren Duncan wrote: At 7:01 AM -0700 8/4/04, Jeff Zucker wrote: It is not a miscellaneous extra that \%attrs is a parameter to virtually every method in the DBI or that passing \%attrs does a fundamentally different thing than passing $dsn, or $sql or $value. I was not referring to \%attrs in my comment. Rather, I see those as being fundamentally the same as $dsn or $sql or $value because those are all *method arguments*. It is just positional vs named arguments, but arguments none-the-less. Except that the other arguments specify what to operate on and \%attrs specifies how to operate. Do you see what I am talking about? I think so, I was only reacting to your statement that the use of tied hashes is miscellaneous and extra. It may not be your preferred API, but it is consistent and central. -- Jeff
Re: DBI 2.0 interface change request
If you change $dbh-{RaiseError}=1 to $dbh-raise_error(1), what is it
you are proposing for DBI-connect( ..., {RaiseError=1, PrintError=0}
)? Handle attributes are a series of name/value pairs.
Er, this is not exactly virgin territory here. Virtually every common
post-wild-west-early-days (sorry DBI, CGI.pm ;) Perl 5 modules uses
some kind of simple named attribute interface. Look at DateTime for
just one recent example. This is also the direction of Perl 6
interfaces.
What more natural way is there in Perl to deal with name/value pairs than a
hash?
Boldly speaking for the Entire Perl Community (ha!), $o-foo( ... {
... }) interfaces are generally considered icky. Who here doesn't
cringe when they see those curly braces in a newly downloaded CPAN
module's POD? It's an annoying, problem-prone way to tack
extensibility onto an API that has otherwise painted itself into a
corner with too many required positional params
(*cough*bind_columns(undef, ...))
And since hashes can be tied to provide privacy and encapsulation,
what rule does it break to use them other than the rule that objects
have round things at the end of their arrows rather than squiggly things?
There are better ways to implement encapsulation and extensibility
than tied hashes. They're called objects and methods :) Again,
these are not theoretical, unsolved problems...
-John
Re: DBI 2.0 interface change request
On Tue, 03 Aug 2004 22:45:46 -0700, Dean Arnold wrote:
Hashrefs are declarativeSQL is declarative...
Methods are procedural.
So? DBI isn't supposed to be SQL, it's supposed to be a database
abstraction interface. The structure and syntax of SQL is
intentionally separate, so much so that DBI doesn't even want to ever
have to parse SQL, let alone try to model its interface after it.
That was not a motivation for the existing interface, AFAIK. And even
if it was, it'd still be misguided :)
I realize many perl users seem hell bent on turning the language into
Java-yuk-foo. Please don't.
Funny, Java-yuk-foo is exactly what I think when I see names like
RaiseError and PrintError ;)
As for me, give me a tie, and let declaration guide me
As has been pointed out, it's pretty hard to, say, prepare or execute
SQL declaratively. But regardless, DBI is not trying to be SQL.
DBI is an interface that takes SQL arguments to some of its functions,
but also includes lots of other functions that don't involved SQL at
all: handle and cursor traits, connecting and disconnecting,
transaction management, fetching, param binding, etc. etc.
This extra functionality is arguably the most important part of DBI,
since the actual SQL must necessarily be allowed to be
vendor-specific. The unifying interface of DBI is made up of the
actual functions that take SQL strings as arguments (not the SQL
strings themselves) plus all the other functions that don't involve
SQL at all, but instead deal with the abstractions generated by the
functions that do accept SQL.
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...
(...I hope! :)
-John
Re: DBI 2.0 interface change request
John Siracusa wrote:
Boldly speaking for the Entire Perl Community (ha!) interfaces like this:
$x-foo(..., {...})
are generally considered icky. Who here doesn't cringe when they
see those curly braces in a newly downloaded CPAN module's POD?
I don't. :-)
Re: DBI 2.0 interface change request
Jochen Wiedmann wrote on 8/4/2004, 3:38 PM:
John Siracusa wrote:
Boldly speaking for the Entire Perl Community (ha!) interfaces like this:
$x-foo(..., {...})
are generally considered icky. Who here doesn't cringe when they
see those curly braces in a newly downloaded CPAN module's POD?
I don't. :-)
Neither do I, but perhaps the wild wolves that raised me, left me with bad coding
habits. Regardless, my flame war detectors are starting to go into the red zone.
--
Your Friendly Neighborhood DBA,
Chuck
Re: DBI 2.0 interface change request
John Siracusa wrote:
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);
That gains absolutely *no* functionality for the burden of loosing
compatibility. Besides, we obviously have different feelings, what's
Perl-ish or not. Please, don't.
Jochen
Re: DBI 2.0 interface change request
On Mon, Aug 02, 2004 at 07:56:47PM -0400, John Siracusa wrote: 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 :) It is indeed DBI 3.0 that you're talking about. I'm thinking of DBI v3 as the version that'll be re-engineered with a perl6 API. Though in practice it may work out that DBI v3 is a 'plain' port to perl6 and it's DBI v4 that gets an API makeover. But that's all some way off yet. Meanwhile, now isn't the time to be getting into debates about such future details. Tim.
Re: DBI 2.0 interface change request
On Tue, 03 Aug 2004 09:35:25 +0200, Jochen Wiedmann That gains absolutely *no* functionality It's a heck of a lot easier to subclass... for the burden of loosing compatibility. There's no reason the old interface couldn't continue to exist. Besides, we obviously have different feelings, what's Perl-ish or not. Sorry, maybe I should have said post-Perl-4-ish ;) On Tue, 3 Aug 2004 10:37:57 +0100, Tim Bunce [EMAIL PROTECTED] wrote: On Mon, Aug 02, 2004 at 07:56:47PM -0400, John Siracusa wrote: 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 :) It is indeed DBI 3.0 that you're talking about. I'm thinking of DBI v3 as the version that'll be re-engineered with a perl6 API. Though in practice it may work out that DBI v3 is a 'plain' port to perl6 and it's DBI v4 that gets an API makeover. But that's all some way off yet. A plain port of the current DBI interface to Perl 6 would be a sin against nature, IMO. Ick :) Meanwhile, now isn't the time to be getting into debates about such future details. Ah well... -John
Re: DBI 2.0 interface change request
John Siracusa wrote: On Tue, 03 Aug 2004 09:35:25 +0200, Jochen Wiedmann That gains absolutely *no* functionality It's a heck of a lot easier to subclass... for the burden of loosing compatibility. There's no reason the old interface couldn't continue to exist. OK, I'll bite Hashrefs are declarativeSQL is declarative... Methods are procedural. I can imagine (even postulate ..see recent mad rantings RE embedded SQL) a fully declarative perl-to-database I/F. I realize many perl users seem hell bent on turning the language into Java-yuk-foo. Please don't. If you're inclined for the same old I'll tell you what I want and how I want it and how to get it i/f, there are plenty of (IMHO misguided) DBIx's to help you get over your jones. rant Why do so many of you hate SQL so much ? I've seen some amazingly intractable perl code (worse still C/C++/Java code) that purports to simplify databaase access. Unless you're dealing with the parts explosion problem, SQL does a pretty good job, and solves most problems, if folks would take a moment to consider the declarative solution. /rant As for me, give me a tie, and let declaration guide me (I promise, this is not a pseudonym for Fabian Pascal), BTW: This probably belongs on dbi-users at this point.. A MAd DEclAratiVe, Dean
Re: DBI 2.0 interface change request
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
