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
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.
+B<NOTE:> The behaviour of a C<my> statement modified with a statement
+modifier conditional or loop construct (e.g. C<my $x if ...>) is
+B<undefined>. The value of the C<my> variable may be C<undef>, any
+previously assigned value, or possibly anything else. Don't rely on
+it. Future versions of perl might do something different from the
+version of perl you try it out on. Here be dragons.
The C<foreach> loop defaults to scoping its index variable dynamically
in the manner of C<local>. However, if the index variable is
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();
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,
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 overriden, but due
+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).
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 overriden as well.
+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 overriden.
+Finally, some built-ins (e.g. C<exists> or C<grep>) can't be overridden.
=head2 Autoloading
projects / p5sagit/p5-mst-13.2.git / blobdiff