Overriding Built-in Functions
Many built-in functions may be overridden, although (like knocking holes in your walls) you should do
this only occasionally and for good reason. Typically, this might be done
by a package attempting to emulate missing built-in functionality on a
non-Unix system. (Do not confuse overriding with overloading, which adds additional
object-oriented meanings to built-in operators, but doesn’t override much
of anything. See the discussion of the overload module in Chapter 13
for more on that.)
Overriding may be done only by importing the name from a
module—ordinary predeclaration isn’t good enough. To be perfectly
forthcoming, it’s the assignment of a code reference to a typeglob that triggers the override, as in *open = \&myopen. Furthermore, the
assignment must occur in some other package; this makes accidental
overriding through typeglob aliasing intentionally difficult. However, if
you really want to do your own overriding, don’t despair, because the
subs pragma lets you predeclare
subroutines via the import syntax, so those names then override the
built-in ones:
use subs qw(chdir chroot chmod chown);
chdir $somewhere;
sub chdir { ... }In general, modules should not export built-in names like open or chdir
as part of their default @EXPORT list,
since these names may sneak into someone else’s namespace and change the
semantics unexpectedly. If the module includes the name in the @EXPORT_OK list instead, importers will be forced to explicitly request that ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access