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

Nathan Wiger <[email protected]> writes:

> Most of the places I've seen them used really well is if
> they walk and talk like other forms:
> 
>    $cgi->param($var, @val);      # traditional
>    $cgi->param($var) = @val;     # lvalue, but same thing

I do not think this is critical. When lvalue subs catch on, the
traditional way will soon be extinct.

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

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

and so on.

And, what would the lvalue routine return? Currently, $a = $b = $c
implies that both $b and $a get the value $c. But with lvalue subs I
can write something like

    yech($foo) = $bar

that assigns $bar to $foo, and returns something else (e.g., the
previous value of $foo). 

    $a = yech($foo) = $bar

now $a will no longer get $bar assigned.

Do we want that?

-- Johan