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