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. -josephThread Previous | Thread Next