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.

Counter-summary: Although the high and low precedence binary ops could be
		 rolled together, the current version of operator overloading
		 is inadequate. An overloaded conjunction or disjunction
		 is *not* an instance of boolification unless I *define*
		 it to be so.


   > >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.  

Not necessarily. What if I am setting up a class that represents expressions
and want to be able to say:

	$x = ExprNode->new();
	$y = ExprNode->new();
	$z = ExprNode->new();
	$exprtree = $x + $y < $z && $z > $x * $y;

I can currently overload + < > * to do this, but not &&. That's broken.


   >     if ($whatever) { A }
   >     else           { B }
   > 
   > Why should that any of those be different than
   > 
   >     $whatever ? A : B;

Because one is a control and one is an operator (i.e. yields a value).
What if I want that value to be another ExprTree?
   

   > 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.

Agreed. This is an internal optimization that that would need to be addressed
if boolean connectives were made overloadable.


   > And what about the negations?  Will !A trigger something special?

Yes. NOT must be overloadable too.


BTW, this is not just theoretical yearnings. I have written three modules
in the past year that do not work as well as they could, simply because it
is not possible to overload && and ||.

Damian