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.
-
-None of the foregoing text applies to C<if/unless> or C<while/until>
-modifiers appended to simple statements. Such modifiers are not
-control structures and have no effect on scoping.
+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();
as part of C<@_> will be a reference to the actual argument given
in the subroutine call, obtained by applying C<\> to that argument.
+You can also backslash several argument types simultaneously by using
+the C<\[]> notation:
+
+ sub myref (\[$@%&*])
+
+will allow calling myref() as
+
+ myref $var
+ myref @array
+ myref %hash
+ myref &sub
+ myref *glob
+
+and the first argument of myref() will be a reference to
+a scalar, an array, a hash, a code, or a glob.
+
Unbackslashed prototype characters have special meanings. Any
unbackslashed C<@> or C<%> eats all remaining arguments, and forces
list context. An argument represented by C<$> forces scalar context. An
module, nor make it harder to read. The line noise is visually
encapsulated into a small pill that's easy to swallow.
+If you try to use an alphanumeric sequence in a prototype you will
+generate an optional warning - "Illegal character in prototype...".
+Unfortunately earlier versions of Perl allowed the prototype to be
+used as long as its prefix was a valid prototype. The warning may be
+upgraded to a fatal error in a future version of Perl once the
+majority of offending code is fixed.
+
It's probably best to prototype new functions, not retrofit prototyping
into older ones. That's because you must be especially careful about
silent impositions of differing list versus scalar contexts. For example,
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:
C<glob>, study the implementation of C<File::DosGlob> in the standard
library.
+When you override a built-in, your replacement should be consistent (if
+possible) with the built-in native syntax. You can achieve this by using
+a suitable prototype. To get the prototype of an overridable built-in,
+use the C<prototype> function with an argument of C<"CORE::builtin_name">
+(see L<perlfunc/prototype>).
+
+Note however that some built-ins can't have their syntax expressed by a
+prototype (such as C<system> or C<chomp>). If you override them you won't
+be able to fully mimic their original syntax.
+
+The built-ins C<do>, C<require> and C<glob> can also be overridden, but due
+to special magic, their original syntax is preserved, and you don't have
+to define a prototype for their replacements. (You can't override the
+C<do BLOCK> syntax, though).
+
+C<require> has special additional dark magic: if you invoke your
+C<require> replacement as C<require Foo::Bar>, it will actually receive
+the argument C<"Foo/Bar.pm"> in @_. See L<perlfunc/require>.
+
+And, as you'll have noticed from the previous example, if you override
+C<glob>, the C<E<lt>*E<gt>> glob operator is overridden as well.
+
+In a similar fashion, overriding the C<readline> function also overrides
+the equivalent I/O operator C<< <FILEHANDLE> >>.
+
+Finally, some built-ins (e.g. C<exists> or C<grep>) can't be overridden.
+
=head2 Autoloading
If you call a subroutine that is undefined, you would ordinarily
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