Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, and wantarray() changes
On Aug 16, 8:21pm, Perl6 RFC Librarian wrote:
# this is perl6
sub foo :lvalue ($new) {
$variable = $new;
}
A nice idea, but one of the reasons for the original proposal was
to make
$foo-bar = $x;
behave the same as:
$foo-bar($x);
Your proposal provides a neat solution for lvalues, but at the cost of
the original aim (or my aim, at least). If you wanted to accept either
of the above then your code would end up looking something like this:
sub foo($argnew) : lvalue($rvalnew) {
$variable = want('lvalue') ? $rvalnew : $argnew;
}
I think that's likely to make things more complicated in the long run.
I'm inclined to say that assignments of the form:
$foo-bar(@baz) = @boz;
Are allowed, but just plain stupid. It's the same as:
$foo-bar(@baz, @boz)
and you're right, Perl can't tell the lvalues and rvalues apart. So
don't do that. If we can fix Perl so that it can tell the above
apart, then good, but I think it's a separate problem to the lvalue
subs.
A
--
Andy Wardley [EMAIL PROTECTED] Signature regenerating. Please remain seated.
[EMAIL PROTECTED] For a good time: http://www.kfs.org/~abw/
Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, and wantarray() changes
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
Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, and wantarray() changes
At 05:49 AM 8/18/00 +1000, Damian Conway wrote: And I keep pointing out that this is only one aspect of lvalue subroutines. The point of an lvalue subroutine is not to make assignment to the return value work, it is to make the return value an *lvalue*. That's a much more general thing, because it allows every other type of modification to work too. The lvalue accessor *shouldn't* be doing the assignment (what if an assignment isn't what I want?). The (overloaded) operator = should do the assignment. To whatever lvalue the lvalue subroutine returns. Or the "assignment" should be done by operator += or operator++ or whatever mutator I'm actually applying to the returned lvalue. SO what you are saying is that the proper execution of "$p-foo(@args) += $val;" should be (equivalent to): 1. Evaluate $val and get an rvalue $rval. 2. Evaluate $p-foo(@args) and get an lvalue $lfoo. 3. Add $rval to the rvalue associated with $lfoo, to get $rbar. 4. call $lfoo-operator=($rbar) to do the actual assignment. Is that about right? When is your RFC about lvalue subs coming, Damian? Damian
