Like the flattened incoming parameter list, the return list is also
flattened on return. So all you have managed to do here is stored
-everything in C<@a> and made C<@b> an empty list. See
+everything in C<@a> and made C<@b> empty. See
L<Pass by Reference> for alternatives.
A subroutine may be called using an explicit C<&> prefix. The
my @oof = @bar; # declare @oof lexical, and init it
my $x : Foo = $y; # similar, with an attribute applied
-B<WARNING>: The use of attribute lists on C<my> declarations is
-experimental. This feature should not be relied upon. It may
-change or disappear in future releases of Perl. See L<attributes>.
+B<WARNING>: The use of attribute lists on C<my> declarations is still
+evolving. The current semantics and interface are subject to change.
+See L<attributes> and L<Attribute::Handlers>.
The C<my> operator declares the listed variables to be lexically
confined to the enclosing block, conditional (C<if/unless/elsif/else>),
the scope of $answer extends from its declaration through the rest
of that conditional, including any C<elsif> and C<else> clauses,
-but not beyond it.
-
-B<NOTE:> None of the foregoing text applies to C<if/unless>,
-C<while/until> or C<for> modifiers appended to simple statements. Such
-modifiers are not control structures and have no effect on scoping. The
-use of such modifiers in conjunction with C<my> is best avoided, as it may
-have unexpected effects. A future release of Perl may define precise
-semantics for constructs such as C<my $foo = 1 if $bar>.
+but not beyond it. See L<perlsyn/"Simple statements"> for information
+on the scope of variables in statements with modifiers.
The C<foreach> loop defaults to scoping its index variable dynamically
in the manner of C<local>. However, if the index variable is
}
[..%ahash back to its initial tied self again..]
+B<WARNING> The code example above does not currently work as described.
+This will be fixed in a future release of Perl; in the meantime, avoid
+code that relies on any particular behaviour of localising tied arrays
+or hashes (localising individual elements is still okay).
+See L<perldelta/"Localising Tied Arrays and Hashes Is Broken"> for more
+details.
+
As another example, a custom implementation of C<%ENV> might look
like this:
=head2 Lvalue subroutines
-B<WARNING>: Lvalue subroutines are still experimental and the implementation
-may change in future versions of Perl.
+B<WARNING>: Lvalue subroutines are still experimental and the
+implementation may change in future versions of Perl.
It is possible to return a modifiable value from a subroutine.
To do this, you have to declare the subroutine to return an lvalue.
my $val;
sub canmod : lvalue {
+ # return $val; this doesn't work, don't say "return"
$val;
}
sub nomod {
all the subroutines are called in a list context.
+=over 4
+
+=item Lvalue subroutines are EXPERIMENTAL
+
+They appear to be convenient, but there are several reasons to be
+circumspect.
+
+You can't use the return keyword, you must pass out the value before
+falling out of subroutine scope. (see comment in example above). This
+is usually not a problem, but it disallows an explicit return out of a
+deeply nested loop, which is sometimes a nice way out.
+
+They violate encapsulation. A normal mutator can check the supplied
+argument before setting the attribute it is protecting, an lvalue
+subroutine never gets that chance. Consider;
+
+ my $some_array_ref = []; # protected by mutators ??
+
+ sub set_arr { # normal mutator
+ my $val = shift;
+ die("expected array, you supplied ", ref $val)
+ unless ref $val eq 'ARRAY';
+ $some_array_ref = $val;
+ }
+ sub set_arr_lv : lvalue { # lvalue mutator
+ $some_array_ref;
+ }
+
+ # set_arr_lv cannot stop this !
+ set_arr_lv() = { a => 1 };
+
+=back
+
=head2 Passing Symbol Table Entries (typeglobs)
B<WARNING>: The mechanism described in this section was originally
sub ioqueue {
local (*READER, *WRITER); # not my!
- pipe (READER, WRITER); or die "pipe: $!";
+ pipe (READER, WRITER) or die "pipe: $!";
return (*READER, *WRITER);
}
($head, $tail) = ioqueue();
done by a package attempting to emulate missing built-in functionality
on a non-Unix system.
-Overriding may be done only by importing the name from a
-module--ordinary predeclaration isn't good enough. However, the
+Overriding may be done only by importing the name from a module at
+compile time--ordinary predeclaration isn't good enough. However, the
C<use subs> pragma lets you, in effect, predeclare subs
via the import syntax, and these names may then override built-in ones:
use attributes __PACKAGE__, \&plugh, q[Ugly('\(")], 'Bad';
For further details on attribute lists and their manipulation,
-see L<attributes>.
+see L<attributes> and L<Attribute::Handlers>.
=head1 SEE ALSO