Peter Scott <[EMAIL PROTECTED]> writes:
>At 06:23 PM 8/9/00 +0000, Nick Ing-Simmons wrote:
>>Damian Conway <[EMAIL PROTECTED]> writes:
>> >Operator overloading is scheduled to be revamped.
>>
>>While I remember - it would be good if overload mechansim
>>could be extended to cover && and ||
>
>Yes.
>
>>as well as & and |
>>with the class deciding if short-circuit happens.
>
>No.  I don't want to see && or || and not know whether it short-circuits 
>without looking in the class interface.  My brain is conditioned through 
>years of C and Perl to expect that they always short-circuit.  This is too 
>venerable a semantic to change.  Please.

The reason I want the class to decide is not to change the semantic meaning
but the implementation - i.e. _when_ it short circuits.

I have an application which overloads all the ops and builds a little parse
tree of objects. When you "look" at the tree it returns the value.

my $a = new Thing;
my $b = new Thing;

my $cond = $a && $b;  # an object 

sub foo
{
 if ($cond)
  {
  }  
}

$a->bind($a_value);
$b->bind($b_value);

foo();

If things worked as I wanted then when foo is called and "looks" at $cond
then overloaded "boolean" operator of $cond would walk the tree and see 
if $a should be considered "true" with its current binding if not 
it would short-circuit tree traversal, if it was it would go look at $b's 
trueness.

Currently it is completely hosed by && and || as perl will not give me 
access to the short-circuited operand so I cannot put it in my tree so 
when it evaluates I get the wrong answers.

(To make app. work I use & and | and make _those_ short circuit - but 
my users and I keep forgetting ...)

I don't think giving overload control over short-circuit is any more
surprising than allowing overloaded '+' to subtract.


-- 
Nick Ing-Simmons

Reply via email to