Filipe Brandenburger <[EMAIL PROTECTED]> writes:
>
>The big problem with || and && is that they don't evaluate their second
>argument until it's needed, that's what allows us to do something like
>`$xxx || die'.
That is still a run-time thing though - so no real barrier to overloading it.
>I remember reading one possible use of it to do a seamless
>Perl to SQL query engine, like writing
>
>select($name eq 'FILIPE' && $salary > 100000);
>
>would do a SQL query. (It wasn't actually like this, but it was something
>like it). I haven't seen any use other than this for overloading && and ||,
>please tell me if there is one.
I have an app which uses overload to cause perl to build a parse
tree (of perl objects). Not being able to overload && and || is
an irritant in this area as VHDL and Verilog that parse is going
to translate to both have equivalent constructs.
>
>Now, this kind of thing above, this would actually be done much better by a
>pluggable parser (or better, a pluggable code generator, that takes the
>abstract syntax tree of the parsed perl code), that instead of generating
>perl bytecode (or whatever bytecode), generates a SQL query.
The aim of my scheme above is to use the perl parser - as a parser
for a language the user is familier with - and build the
alien parse tree from it.
>
>As I foresee it, dealing with the late evaluation needed for && and ||
>wouldn't be worth the little win of being able of defining the Perl<->SQL
>translator with overload.
Dealing the the late eval is easy just let the overload code do it
same as for any other overload.
>
>Please tell me if there really is an use for overloading && and || that
>would not be better done with source filtering, then I will (maybe)
>reconsider my opinion.
>
>- Branden
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
