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
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. :-)
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
> 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-da
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
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 wa
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, 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
> 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-da
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,
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 wri
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 ha
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
13 matches
Mail list logo
