Chaim Frenkel wrote:
>
> NW> @stuff = docoolstuff(%hash, $var, @array);
> NW> @stuff = docoolstuff(%hash, $var) = @array;
>
> Then assignment arguments must be a the tail of the prototype. A bit
> of limitation.
No, that's not true:
@stuff = docoolstuff(@stuff) = %hash, $var;
@stuff = docoolstuff = @stuff, %hash, $var;
All this assumes that -internals sorts out how to pass hashes and arrays
around intact. If this doesn't happen, and they're still flattened, then
we'll have to revisit this. I'd rather assume "-internals will do the
right thing" for now.
> Hmm, your proposal also make a non-lvaluable subroutine lvaluable. With
> arbitrary values.
>
> sub foo { launch_missles if $_[0] }
> foo = 35;
Yes, by the above example, either of these would launch_missles
identically:
foo(35);
foo = 35;
Just to reemphasize one thing incredibly strongly: The subs I propose be
enabled by default are NOT what anyone who understands lvalues would
consider lvalue subs. They are rvalue subs that just happen to be in the
left side of a =. They do NOT act as lvalues. They act as rvalues. As
such, any scoping issues are moot, because the scoping is rvalue'd, even
though the sub is used as an lvalue.
That's why there's the restriction of only being able to use =. These
aren't true lvalues, and can't possibly support ++, s///, and so on. The
idea is to make them just able to handle = without having to rewrite the
sub. The idea is to make easy things easier, ala RFC 152. Instead of
requiring a whole rewritten or overloaded sub, you say:
"Hey you can use whichever one you like better:"
$cgi->param($var, @val);
$cgi->param($var) = @val;
And param() works automatically, IDENTICALLY (and I mean it), in either
calling form.
-Nate
