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
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.
Matt Sergeant wrote:
And easier to implement in C.
I never found any difficulties in the methods handling properties?
Jochen
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
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
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
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:
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
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
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
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
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. :-)
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
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
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
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,
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
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
18 matches
Mail list logo
