the aliasing, and does not update any arguments.
The return value of the subroutine is the value of the last expression
-evaluated. Alternatively, a return statement may be used exit the
+evaluated. Alternatively, a return statement may be used to exit the
subroutine, optionally specifying the returned value, which will be
evaluated in the appropriate context (list, scalar, or void) depending
on the context of the subroutine call. If you specify no return value,
supplies a scalar context.
+A note about C<local()> and composite types is in order. Something
+like C<local(%foo)> works by temporarily placing a brand new hash in
+the symbol table. The old hash is left alone, but is hidden "behind"
+the new one.
+
+This means the old variable is completely invisible via the symbol
+table (i.e. the hash entry in the C<*foo> typeglob) for the duration
+of the dynamic scope within which the C<local()> was seen. This
+has the effect of allowing one to temporarily occlude any magic on
+composite types. For instance, this will briefly alter a tied
+hash to some other implementation:
+
+ tie %ahash, 'APackage';
+ [...]
+ {
+ local %ahash;
+ tie %ahash, 'BPackage';
+ [..called code will see %ahash tied to 'BPackage'..]
+ {
+ local %ahash;
+ [..%ahash is a normal (untied) hash here..]
+ }
+ }
+ [..%ahash back to its initial tied self again..]
+
+As another example, a custom implementation of C<%ENV> might look
+like this:
+
+ {
+ local %ENV;
+ tie %ENV, 'MyOwnEnv';
+ [..do your own fancy %ENV manipulation here..]
+ }
+ [..normal %ENV behavior here..]
+
+It's also worth taking a moment to explain what happens when you
+localize a member of a composite type (i.e. an array or hash element).
+In this case, the element is localized I<by name>. This means that
+when the scope of the C<local()> ends, the saved value will be
+restored to the hash element whose key was named in the C<local()>, or
+the array element whose index was named in the C<local()>. If that
+element was deleted while the C<local()> was in effect (e.g. by a
+C<delete()> from a hash or a C<shift()> of an array), it will spring
+back into existence, possibly extending an array and filling in the
+skipped elements with C<undef>. For instance, if you say
+
+ %hash = ( 'This' => 'is', 'a' => 'test' );
+ @ary = ( 0..5 );
+ {
+ local($ary[5]) = 6;
+ local($hash{'a'}) = 'drill';
+ while (my $e = pop(@ary)) {
+ print "$e . . .\n";
+ last unless $e > 3;
+ }
+ if (@ary) {
+ $hash{'only a'} = 'test';
+ delete $hash{'a'};
+ }
+ }
+ print join(' ', map { "$_ $hash{$_}" } sort keys %hash),".\n";
+ print "The array has ",scalar(@ary)," elements: ",
+ join(', ', map { defined $_ ? $_ : 'undef' } @ary),"\n";
+
+Perl will print
+
+ 6 . . .
+ 4 . . .
+ 3 . . .
+ This is a test only a test.
+ The array has 6 elements: 0, 1, 2, undef, undef, 5
+
+In short, be careful when manipulating the containers for composite types
+whose elements have been localized.
+
=head2 Passing Symbol Table Entries (typeglobs)
[Note: The mechanism described in this section was originally the only
chdir $somewhere;
sub chdir { ... }
+To unambiguously refer to the builtin form, one may precede the
+builtin name with the special package qualifier C<CORE::>. For example,
+saying C<CORE::open()> will always refer to the builtin C<open()>, even
+if the current package has imported some other subroutine called
+C<&open()> from elsewhere.
+
Library modules should not in general export builtin names like "open"
or "chdir" as part of their default @EXPORT list, because these may
sneak into someone else's namespace and change the semantics unexpectedly.
they would get the default imports without the overrides.
+Note that such overriding is restricted to the package that requests
+the import. Some means of "globally" overriding builtins may become
+available in future.
+
=head2 Autoloading
If you call a subroutine that is undefined, you would ordinarily get an