At 12:00 PM 20/04/2001 -0700, Nathan Wiger wrote:
>It looks like Branden took the vtable names from RFC 159, which is a
>modification of 'use overload' ops to object member functions.
Yes, that was one of my biggest inspirations.
>During
>our discussions of this on -objects, I remember Damian emphasizing that
>you want as much granularity as possible with anything that's overloaded
>(especially concerning the ability to overload || and &&).
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'. 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.
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.
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. And that will be even more so if we consider that
we'll have a way to translate *all* the source code, with the pluggable
parsers.
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
