First, that's not the final interface, just a prove of concept.
> maybe a (&) prototype might help
That's the plan, but for testing and demonstration I needed a lambda.
> "because that's how it works", ie, enforced cargo-culting.
I don't understand your point here.
There are different use cases at my job already
local $"=","; my $sth = $dbh->prepare( "SELECT * FROM $table WHERE lastname = $lastname AND firstname IN (@firstnames) " ); $sth->execute( $lastname, @firstnames );
I want to change it to something like:
my $sth = $dbh->xprepare( ph { "SELECT * FROM $_table WHERE lastname = $lastname AND firstname IN (@firstnames) " }); $sth->xexecute();
(not sure yet, but methods can't have prototypes and DBI allows to hook in with callbacks)
> (access the variables outside their scopes, delay the interpolation), so that's magic where the implementation leaks into the calling context, the wrong kind of magic IMHO.
I don't get your point, nothing is leaking here. I'm overwriting the pad with references of new vars. This means all effects are restricted to the code block, which is only executed once.
My goals are:
Cheers Rolf
(addicted to the Perl Programming Language and ☆☆☆☆ :)
Wikisyntax for the Monastery
While writing this post I had to re-edit the "legacy" part twice, because I mistyped repeated variables.
And it's still wrong. ;-)
In reply to Re^2: RFC: Placeholder creation for SQL statements
by LanX
in thread RFC: Placeholder creation for SQL statements
by LanX
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |