>>>>> "JV" == Johan Vromans <[EMAIL PROTECTED]> writes:
>> These two should have different actions.
>>
>> $foo = &foo;
>> &foo = $foo;
>>
>> Perl needs a value for one, and a reference for the other.
JV> I'm not sure I understand what you trying to say here. Please explain.
The difference between RHS and LHS. RHS, perl is manipulating values.
With LHS perl is manipulating locations, storage areas. Where to put
those values from the RHS.
So RHS are values (even if a reference, it's meaning as a value is of
interest) LHS are pointers. Where to save the value from RHS.
So an lvalue sub on the RHS should be returning a _value_ an lvalue
sub on the LHS should be tell Perl where to shove^w put the value.
(Hey, perl, I want that dohickey put into my array at position 42.)
JV> - make it unfeasable for methods.
>>
>> Why? All methods for the same OO hierarchy should have the same signature.
JV> Assume class Foo has a method m that returns a scalar lvalue, and
JV> class Bar has a method m that returns an array lvalue. The following
JV> code is now perfectly legal (though weird):
JV> my $o = $some_condition ? Foo::->new() : Bar::->new();
JV> $o->m = another_sub();
JV> 'another_sub' calls wantarray. What should it return?
That's the point. Perl has to examine $o->m 's return to determine
what is going on. So $o-> has to be called first. And the resulting
reference queried about it's type. And then the want() will return
the correct context.
In the another_sub( lvalue_sub ), lvalue_sub has to be defered until
the first time it is called. (Unless Damian thinks that reaccessing
it each time will make more sense.)
<chaim>
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
