Re: RFC 159 (v1) True Polymorphic Objects

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