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,
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