This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Simple assignment lvalue subs should be on by default
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 24 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 154
Status: Developing
=head1 ABSTRACT
Currently, there are several competing RFC's for lvalue subs, all of
which do things a little differently to please different groups.
This RFC proposes a means by which they can mostly coexist peacefully,
simply by making simple assignment-only lvalue subs the default.
=head1 DESCRIPTION
=head2 Simple lvalue subs
RFC's 107 and 118 propose a very simplistic lvalue sub mechanism which
seeks to make lvalue and rvalue subs more or less directly equivalent.
While nice, this is truly only suitable for assignment. Still, this
approach provides powerful capabilities:
$cgi->param($name) = @newval;
$oldpath = $tree->path('L','R') = 'R';
@document = ($title, $junk, $r->xml_extract) = <STDIN>;
Here, assignment can be used to dynamically call subs in lvalue and
rvalue contexts, allowing powerful syntactic constructs. This presents
functionality akin to tie, without all the unnecessary overhead or pain
tie involves.
This RFC proposes that this capability be on by default. No C<:lvalue>
constraint would be required. Instead, the sub would obey the B<exact>
same rules as an rvalue sub, including sub parameters, @_, scoping, and
so forth:
package CGI;
sub param ($var, @val) {
# do stuff
}
$r = new CGI;
$r->param($var, @val); # ok
$r->param($var) = @val; # ok too
$r->param = $var, @val; # ok, but silly looking
The key to the proposal is this: lvalue and rvalue versions of a sub
would work I<identically>, and both would be enabled by default.
I<However>, assignment is the only valid operator for these default
lvalue subs. Attempts to use other operators, such as ++ or s/// on
these subs would yield an error like:
Attempt to modify simple lvalue sub, only = is allowed
Even with this restriction, lvalue subs in this format give us lots of
syntax advantages. As users, not only are we allowed to choose which
form suits a given situation:
$cgi->param($name) = split /\s+/, "Nathan Wiger";
($user, $r->uid('anon')) = @data;
But it also allows you to chain subs together, as you can do in Perl 5
with basic data types and even tied variables:
@htmldoc = ($title, $r->htmlify) = <FILE>;
If overused, this could be gross. However, if used properly this greatly
increases the amount of Laziness and Impatience you can have as a Perl
programmer. The above example would require at least 2-3 lines with
several "in-betweener" variables in Perl 5. [1] As written, it's quite
readable and obvious what it does.
=head2 Complex lvalue subs
Damian has an upcoming RFC on this topic, and it is being widely
discussed. These complex lvalue subs should have several properties
differentiating them from the simple lvalue subs described in this RFC:
1. True lvalue scoping
2. Ability to accept any operation
3. Return an lvalue which is then evaluated like any
other lvalue
These complex subs are outside the scope of this RFC. However, these
would be enabled with the C<:lvalue> constraint, indicating that they
are fundamentally different from rvalue subs.
By using the C<:lvalue> constraint on these fundamentally different
subs, we can allow both the simple and complex lvalue subs to coexist.
=head1 IMPLEMENTATION
Enable lvalue and rvalue versions of subs to be used interchangeably by
default. I<Everything> about the two (including scoping) should be
identical.
=head1 MIGRATION
None. This introduces new functionality, and since it does not require
the use of an C<:lvalue> constraint requires no code translation.
=head1 NOTES
[1] Or unreadable syntactic sugar. Take your pick. Either way it's
nastier than the example of chained lvalue subs presented.
=head1 REFERENCES
RFC 107: lvalue subs should receive the rvalue as an argument
RFC 118: lvalue subs: parameters, explicit assignment, and wantarray()
changes
RFC 57: Subroutine prototypes and parameters
