At 07:04 PM 8/17/00 +0200, Johan Vromans wrote:
>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) = ...
This is a pure lvalue...
> $cgi->param($var) += ...
This is not a pure lvalue, but rather both an lvalue and an rvalue,
equivalent to:
$cgi->param($var) = $cgi->param($var) + ...
It should evaluate $cgi->param($var) twice, once as an rvalue, and once as
an lvalue.
> $cgi->param($var) =~ s///
This is a tricky one... What should the proper result of:
$cgi->param($var) = "Value constrained to less than 80 characters";
$cgi->param($var) =~ s/./FOO/g;
be? Should it be allowed to change the value of $cgi->param($var) to more
than 80 characters? My though is that it should act like:
{ my $string = $cgi->param($var);
$string =~ s/./FOO/g;
$cgi->param($var) = $string;
}
and $cgi->param() can catch any constraint violations like normal.
> for ( $cgi->param($var) ) {
> $_ = ...
> }
> sysread($fh,$cgi->param($var),...)
These I'm uncertain how to deal with...
>and so on.
>
>And, what would the lvalue routine return?
I would say, by -convention-, it should return the new rvalue of the lvalue:
{ my $inval = 0;
sub foo : lvalue($val) {
$inval = $val if defined($val) && $val < 10;
return $inval;
}
}
>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?
Sometimes it would be nice. Why forbid it?
>-- Johan
