Front page | perl.perl5.porters |
Postings from March 2000
On Mon, 20 Mar 2000 16:11:35 +0100 domo@computer.org (Dominic Dunlop) wrote:
* OK, OK. I happen to agree that qs// would be helpful to a lot of
* people. But please don't rant. It just makes me move closer to
* writing that long-reply-post-with-no-patches-in-it filter I've been
* considering.
As much as I'd like to write Perl guts, I just don't have the stomach
for dealing with p5p. I mean that in the nicest possible way given
the words I just used.
* Putting words into your mouth (and using a long spoon), it seems to
* me that what you want could be satisfied by
*
* use esql; # Argue about the name later, if at all!
* ...
* $SIG{__SQLERR__} = \&myhandler;
* ...
* @result = qs/select @cols from $table where $col = $val/;
Something like that.
If the implementation backing up qs// (the smarts of which could be
entirely Perl) were clever enough, it would know that @cols as the
columns argument to select should be expanded with commas, $val
should be fully quoted (and possibly depending on the type of
$col) and so on. That of course would be the most highly evolved
"smart" behavior.
I'm a big fan of "do what I mean" smarts rather than something
more general but explicit like sprintf. In this case anyway.
* Given that support for C<use MyDreamPerl> (or some sufficient subset
* thereof) appeared reasonably promptly in Perl 5, would my suggestion
* fill the need you perceive?
I believe so.
* Given that the medium-complex underpinnings of C<use esql> would not
* be part of the core, and would need to be maintained separately, can
* you suggest a constituency that might be prevailed upon to take
* responsibility for development and maintenance?
I don't want to have anything to do with the core implementation but
I might be persuaded to write the Perl components of the module and
possibly the XS. I could certainly at least offer discussion on the
API that would make a smart qs// possible.
-joseph
Thread Previous
|
Thread Next