Summary: I think these should all simply break down into a single
Boolification test of some sort, as occurs already with operator
overload.
>LOGHIGHAND Called in && context
>LOGHIGHOR Called in || context
>LOGLOWAND Called in and context
>LOGLOWOR Called in or context
>LOGIFELSE Called in ?: context
I don't see that those should be any different from one another.
The essential feature in all of them is simply a Boolean test.
Boolean tests occur in many places. if/unless/while/until
also use them.
You can have your full if:
if ($whatever) { A }
else { B }
Why should that any of those be different than
$whatever ? A : B;
Why should the pairs
A && B
A and B
and
A || B
A or B
be any different? It's simply a matter of precedence.
If someone wrote parens around (3+4)*5 to alter the default
precedence, I shouldn't expect a different operator overload
to trigger. Same here, whether the non-traditional grouping is
effected by parens are using a different operator:
(A) and (B)
(A) && (B)
Please also consider this:
% perl -MO=Deparse -e 'B() if A()'
B if A ;
-e syntax OK
% perl -MO=Deparse -e 'A() && B()'
B if A ;
-e syntax OK
The reverse if/unless tests are really just flow-control logicals
written funny (or vice versa, if you prefer). Since "A && B" really
becomes "B if A", you'll have to tackle that there, too. And even
if it didn't, it would seem something to be addressed.
And what about the negations? Will !A trigger something special?
Is this different from an unless? I don't think it should be,
irrespective of the current op/byte codes generate:
% perl -MO=Deparse -e 'A() || B()'
B unless A ;
-e syntax OK
% perl -MO=Deparse -e 'B() unless A()'
B unless A ;
-e syntax OK
% perl -MO=Deparse -e 'B() if !A()'
B if not A ;
-e syntax OK
Summary: I think these should all simply break down into a single
Boolification test of some sort, as occurs already with operator
overload.
--tom
