Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, and wantarray() changes

As Graham pointed out, is an lvalue sub supposed to act like a tie or
like a variable.

If it acts like a variable it can't be a gatekeeper.

Hmm, what if the sub gets a chance to look at the value before acting.

Checks the value. If good returns a reference to the correct variable
to save it in.

If it needs to twiddle some frobs, does the frobing and then returns
undef to tell perl to pass on the original value as the value of
the assignment. Otherwise, the value returned  (possibly a dummy
variable) is passed on as the value.

What about += .... That's a double access...

Oh, well, perhaps thinkging of it as a tie would be better.

<chaim>

>>>>> "JV" == Johan Vromans <[email protected]> writes:

JV> However, if an lvalue sub is an lvalue, it must be an lvalue in _all_
JV> respects. 

JV>     $cgi->param($var) = ...
JV>     $cgi->param($var) += ...
JV>     $cgi->param($var) =~ s///
JV>     for ( $cgi->param($var) ) {
JV>         $_ = ...
JV>     }
JV>     sysread($fh,$cgi->param($var),...)

JV> and so on.

-- 
Chaim Frenkel					     Nonlinear Knowledge, Inc.
[email protected]				               +1-718-236-0183