Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, and wantarray() changes
On Thu, Aug 17, 2000 at 05:10:40PM -0400, Buddha Buck wrote: > 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. The order of those two is debatable. How do you know what context to evaluate the RHS in ? > 3. Add $rval to the rvalue associated with $lfoo, to get $rbar. > 4. call $lfoo->operator=($rbar) to do the actual assignment. No. you perform normal assignment. If the lvalue return has = overloaded then it will be called. Graham.
Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, and wantarray() changes
On Fri, Aug 18, 2000 at 12:25:42AM -0400, Chaim Frenkel wrote: > As Graham pointed out, is an lvalue sub supposed to act like a tie or > like a variable. Both. As Damian points out the lvalue sub must return something that can be used as an lvalue. Normal assignment hen happens. So the result will be the same as assigning to a variable, if that variable is tied it can change the resutl value of the assign. Graham.
Re: RFC 128 (v1) Subroutines: Extend subroutine contexts to include name parameters and lazy arguments
> DC> * Label an argument such that there is no corresponding named > DC> parameter. > > Could this be eased slightly? How about a %rest hash, if supplied > in the prototype would absorb the unused named parameters? Yes, I've been rethinking that in light of my immediately previous posting about C. I suspect that this constraint should only be applied under use strict, or better yet under the influence of a 'strict_args' subroutine attribute. Damian
Re: RFC 128 (v1) Subroutines: Extend subroutine contexts to include name parameters and lazy arguments
> "DC" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: DC> * Label an argument such that there is no corresponding named DC> parameter. Could this be eased slightly? How about a %rest hash, if supplied in the prototype would absorb the unused named parameters? DC> =head1 IMPLEMENTATION DC> Definitely S.E.P. What does that mean? -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, and wantarray() changes
Then assignment is the gatekeeper? But what information will the lvalue sub have for deciding what to make lvaluable? > "DC" == Damian Conway <[EMAIL PROTECTED]> writes: DC> And I keep pointing out that this is only one aspect of lvalue subroutines. DC> The point of an lvalue subroutine is not to make assignment to the return value DC> work, it is to make the return value an *lvalue*. That's a much more general DC> thing, because it allows every other type of modification to work too. DC> The lvalue accessor *shouldn't* be doing the assignment (what if an assignment DC> isn't what I want?). DC> The (overloaded) operator = should do the assignment. To whatever lvalue DC> the lvalue subroutine returns. DC> Or the "assignment" should be done by operator += or operator++ or DC> whatever mutator I'm actually applying to the returned lvalue. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
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.
> "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 FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
RFC 128 (v2) Subroutines: Extend subroutine contexts to include name parameters and lazy arguments
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Subroutines: Extend subroutine contexts to include name parameters and lazy arguments
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 18 August 2000
Last Modified: 18 August 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 128
=head1 ABSTRACT
This RFC proposes that subroutine argument context specifiers be
extended in several ways, including allowing parameters to be typed and
named, and that a syntax be provided for binding arguments to named
parameters.
=head1 CHANGES
Added section describing named parameter interaction with named higher-order
function placeholders.
=head1 DESCRIPTION
It is proposed that the existing subroutine "prototype" mechanism
be replaced by optional formal parameter lists that allow parameters
to be named and their contexts specified.
The syntax for this would be:
sub subname ( type context(s) parameter_name : parameter_attributes ,
type context(s) parameter_name : parameter_attributes ,
type context(s) parameter_name : parameter_attributes ;
# end of required parameters
type context(s) parameter_name : parameter_attributes ,
# etc.
) : subroutine_attributes
{ body }
Each of the four components of a parameter specification -- type,
context, name, and attributes -- would be optional.
=head2 Contexts
The context specifiers would be:
$ parameter is scalar
@ parameter is array (eats remaining args)
% parameter is hash (eats remaining args)
/ parameter is qr'd string
& parameter is subroutine reference or block
* parameter is typeglob (assuming they still exist)
Note that any of these specifiers may appear in any position in a
parameter list (especially C<&>, which would no longer be constrained to
the first position).
The following context modifiers would be available:
\ parameter must be a reference,
magically en-reference arg if necessary
? argument is lazily evaluated
^ (& only) terminate curry propagation on argument
Note that the semantics of the \ modifier would be altered somewhat
so that a reference is I passed for that parameter.
It would retain its magical en-referencing coercion:
\$ argument must be scalar ref or start with $
scalar var magically en-referenced
\@ argument must be array ref or start with @,
array var magically en-referenced
\% argument must be hash ref of start with %,
hash var magically en-referenced
\/ argument must be qr'd string or /.../ or m/.../
/.../ or m/.../ magically qr'd to en-reference
\& arg must be sub reference, curried function, or block
block converted to anonymous sub ref
\* arg must be something convertible to a typeglob
typeglob magically en-referenced
=head3 Context classes
The revised syntax would also allow I to be specified.
A context class aggregates two or more alternative contexts, allowing
any one of them to be the context for corresponding argument.
For example:
sub mymap ([\/&?$]@) {...}
Here, the first argument must be either a /.../ pattern (or qr), or a
block (or sub ref), or a lazily evaluated scalar (see below). In parsing
that argument the various possible contexts are considered left-to-right
and the first context that allows the argument to be parsed is used.
Note that context classes may also have modifiers:
sub mymap (^[\/&?$]@) {...}
In this example, no matter what the first argument is, it does not propagate currying
(see below).
A context class may only contain context specifiers that yield scalar
parameters. Hence, a context class may contain any of the following
specifiers (any of which may also have C<^> or C modifiers):
$ / \$ \/
& * \& \*
\@ \%
but not:
@ %
A context class always yields a scalar parameter.
=head3 Lazy evaluation
If the C modifier is used for a particular parameter, that parameter
is lazily evaluated. This means that it is only evaluated when the
corresponding named parameter (see below) -- or the corresponding element
of @_ -- is accessed in some way. Passing the parameter to another
subroutine or returning it as an lvalue does not count as an access.
If the C modifier is applied to a C<@> parameter (which eats the
remaining arguments), those remaining arguments are not evaluated
until the corresponding element of the array is accessed. Iteration
through such an array (i.e. in a C or C) only evaluates
one element per iteration.
If the C modifier is a
RFC 128 (v1) Subroutines: Extend subroutine contexts to include name parameters and lazy arguments
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Subroutines: Extend subroutine contexts to include name parameters and lazy arguments
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 17 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 128
=head1 ABSTRACT
This RFC proposes that subroutine argument context specifiers be
extended in several ways, including allowing parameters to be typed and
named, and that a syntax be provided for binding arguments to named
parameters.
=head1 DESCRIPTION
It is proposed that the existing subroutine "prototype" mechanism
be replaced by optional formal parameter lists that allow parameters
to be named and their contexts specified.
The syntax for this would be:
sub subname ( type context(s) parameter_name : parameter_attributes ,
type context(s) parameter_name : parameter_attributes ,
type context(s) parameter_name : parameter_attributes ;
# end of required parameters
type context(s) parameter_name : parameter_attributes ,
# etc.
) : subroutine_attributes
{ body }
Each of the four components of a parameter specification -- type,
context, name, and attributes -- would be optional.
=head2 Contexts
The context specifiers would be:
$ parameter is scalar
@ parameter is array (eats remaining args)
% parameter is hash (eats remaining args)
/ parameter is qr'd string
& parameter is subroutine reference or block
* parameter is typeglob (assuming they still exist)
Note that any of these specifiers may appear in any position in a
parameter list (especially C<&>, which would no longer be constrained to
the first position).
The following context modifiers would be available:
\ parameter must be a reference,
magically en-reference arg if necessary
? argument is lazily evaluated
^ (& only) terminate curry propagation on argument
Note that the semantics of the \ modifier would be altered somewhat
so that a reference is I passed for that parameter.
It would retain its magical en-referencing coercion:
\$ argument must be scalar ref or start with $
scalar var magically en-referenced
\@ argument must be array ref or start with @,
array var magically en-referenced
\% argument must be hash ref of start with %,
hash var magically en-referenced
\/ argument must be qr'd string or /.../ or m/.../
/.../ or m/.../ magically qr'd to en-reference
\& arg must be sub reference, curried function, or block
block converted to anonymous sub ref
\* arg must be something convertible to a typeglob
typeglob magically en-referenced
=head3 Context classes
The revised syntax would also allow I to be specified.
A context class aggregates two or more alternative contexts, allowing
any one of them to be the context for corresponding argument.
For example:
sub mymap ([\/&?$]@) {...}
Here, the first argument must be either a /.../ pattern (or qr), or a
block (or sub ref), or a lazily evaluated scalar (see below). In parsing
that argument the various possible contexts are considered left-to-right
and the first context that allows the argument to be parsed is used.
Note that context classes may also have modifiers:
sub mymap (^[\/&?$]@) {...}
In this example, no matter what the first argument is, it does not propagate currying
(see below).
A context class may only contain context specifiers that yield scalar
parameters. Hence, a context class may contain any of the following
specifiers (any of which may also have C<^> or C modifiers):
$ / \$ \/
& * \& \*
\@ \%
but not:
@ %
A context class always yields a scalar parameter.
=head3 Lazy evaluation
If the C modifier is used for a particular parameter, that parameter
is lazily evaluated. This means that it is only evaluated when the
corresponding named parameter (see below) -- or the corresponding element
of @_ -- is accessed in some way. Passing the parameter to another
subroutine or returning it as an lvalue does not count as an access.
If the C modifier is applied to a C<@> parameter (which eats the
remaining arguments), those remaining arguments are not evaluated
until the corresponding element of the array is accessed. Iteration
through such an array (i.e. in a C or C) only evaluates
one element per iteration.
If the C modifier is applied to a C<%> parameter (which eats the
remaining arguments), the odd arguments (that are mapped to keys) are
immediately evaluated, but the even
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
Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, and wantarray() changes
Buddha Buck <[EMAIL PROTECTED]> writes:
> > $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.
I'd say it must evaluate only once. That's the whole idea behind the
+= and friends. (And don't ask me how to do it. I don't know.)
> > for ( $cgi->param($var) ) {
> > $_ = ...
> > }
> > sysread($fh,$cgi->param($var),...)
>
> These I'm uncertain how to deal with...
You get the idea...
-- Johan
Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, and wantarray() changes
Damian Conway <[EMAIL PROTECTED]> writes: > 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. Exactly! -- Johan
Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, and wantarray() changes
[Quoting Graham Barr, on August 17 2000, 18:32, in "Re: RFC 118 (v1) lva"] > if $b happens to be tied and FETCH returns a different value to what Yes, tie is along the same lines. -- Johan
Re: RFC 97 (v1) prototype-based method overloading
Peter Buckingham <[EMAIL PROTECTED]> writes: > >There are a couple of reasons for overloading. simple arithmetic operations, you >can use plus(int, int), plus(float, float). another approach is to use >genericity like in eiffel, and the templates in C++, which is probably better in >the sense that you only have one function ie plus(, ). And of course perl has plus(,) as its default ;-) If that is "better" why are we suggesting we change it ? -- Nick Ing-Simmons
Re: RFC 98 (v1) context-based method overloading
David L . Nicol <[EMAIL PROTECTED]> writes:
>It will run faster, because it doesn't have to evaluate
>the want(). (97,98) doesn't invalidate the current way of doing
>things, it just gives a new way. And in syntax that is currently
>erroneous.
Consider :
sub outer
{
$object->aSub;
}
The test for want still has to be done (implicitly) so that outer
can decide which version of aSub to call depending on context
that outer was called in.
--
Nick Ing-Simmons
Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, and wantarray() changes
> I hate to add a "me too" but I think this is right on. I also think that > Nat's proposal and several other discussions overlook some stuff about > lvalue subs. 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 > > The second one, then, just makes it more obvious what's going on. But it > shouldn't change the behavior of the sub. In fact, these two should > *both* be valid options for setting $var. Then the programmer can choose > their preferred style. 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. Damian
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
Merge RFC's 107 and 118 (was Re: RFC 118 (v1) lvalue subs)
Buddha Buck wrote:
>
> At 09:21 AM 8/17/00 -0700, Nathan Wiger wrote:
>
> >$cgi->param($var, @val); # traditional
> >$cgi->param($var) = @val; # lvalue, but same thing
> >
> >The second one, then, just makes it more obvious what's going on. But it
> >shouldn't change the behavior of the sub. In fact, these two should
> >*both* be valid options for setting $var. Then the programmer can choose
> >their preferred style.
>
> OK, this is where we differ. I see no reason why those two should
> necessarily be the same. Why couldn't the first be a normal function
> (returning an rvalue) rather than an assignment?
I don't think your and my approaches are necessarily incompatible. But
both of us would have to compromise a little. In the above examples, I
don't see why it couldn't return a value *and* do an assignment. This is
why I think Andy's simple proposal is so robust:
1) $date->format('HH:MM'); # set format, discard results
2) $oldformat = $date->format('HH:MM'); # same, save results
3) $date->format = 'HH:MM';# set format, discard results
4) $oldformat = $date->format = 'HH:MM'; # same, save results
Making the subs work differently would necessitate something like having
to use form (2) if you wanted the value back, but use form (3) if you
want to set the value. This part strikes me as silly.
> To me, it's "clear" that the first version is properly written as:
>
> $tree->path('L','R','R');
>
> and the second as:
>
> $tree->path('L','R')='R';
What if you wanted to do something like this:
$oldpath = $tree->path('L','R') = 'R';
Now, here's a compromise that I think could meld the two RFC's together:
1. Make the lvalue subs be able to take different
args and do stuff slightly differently (Nat's)
2. But overall, make them work exactly the same as
rvalue subs if you want them to (Andy's)
So, per Andy's proposal, put everything in @_. However, take Nat's idea
and allow for special slots in an lvalue context. That way, I as the
author can either make the lvalue sub work like a normal sub (so I can
cascade them), or as a very specialized sub (so I can get the benefits
of the = operator like your example). TMTOWTDI.
Thoughts? Everyone's acting like the two are incompatible but I don't
think they are at all. If Nat's RFC makes the :lvalue arglist optional I
think the two can be merged as-is (assuming everyone compromises just a
little).
-Nate
Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, and wantarray() changes
At 09:21 AM 8/17/00 -0700, Nathan Wiger wrote:
>$cgi->param($var, @val); # traditional
>$cgi->param($var) = @val; # lvalue, but same thing
>
>The second one, then, just makes it more obvious what's going on. But it
>shouldn't change the behavior of the sub. In fact, these two should
>*both* be valid options for setting $var. Then the programmer can choose
>their preferred style.
OK, this is where we differ. I see no reason why those two should
necessarily be the same. Why couldn't the first be a normal function
(returning an rvalue) rather than an assignment?
Or, more concretely, given:
$tree->path('L','R','R');
which is the "correct" interpretation?
1) return the subtree rooted on the right child of the right child of the
left child of root; or
2) set the right child of the left child of root to the scalar value 'R'
To me, it's "clear" that the first version is properly written as:
$tree->path('L','R','R');
and the second as:
$tree->path('L','R')='R';
I don't mind if a programmer would choose to support $p->foo(@args,$val);
over $p->foo(@args)=$val; I don't even mind if a programmer chose to
support both. But the programmer should have the choice of making them
mean different things, if that's what the problem domain calls for.
>-Nate
Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, and wantarray() changes
On Thu, Aug 17, 2000 at 07:04:40PM +0200, Johan Vromans wrote: > 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? You already do with $a = $b = $c if $b happens to be tied and FETCH returns a different value to what was passed to STORE $a = $b = $c Does not mean $a will be assign $c, it means $a will get the result of assigning $c to $a. That is something different. Graham.
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
Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, and wantarray() changes
Andy Wardley wrote: > > 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. I hate to add a "me too" but I think this is right on. I also think that Nat's proposal and several other discussions overlook some stuff about lvalue subs. 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 The second one, then, just makes it more obvious what's going on. But it shouldn't change the behavior of the sub. In fact, these two should *both* be valid options for setting $var. Then the programmer can choose their preferred style. -Nate
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/
