@@ -6716,8 +6716,14 @@ would have semantics similar to the following:
67166716 croak "Compilation failed in require";
67176717 }
67186718
6719- foreach $prefix (@INC) {
6720- if (ref($prefix)) {
6719+ local $INC;
6720+ # this type of loop lets a hook overwrite $INC if they wish
6721+ for($INC = 0; $INC < @INC; $INC++) {
6722+ my $prefix = $INC[$INC];
6723+ if (!defined $prefix) {
6724+ next;
6725+ }
6726+ if (ref $prefix) {
67216727 #... do other stuff - see text below ....
67226728 }
67236729 # (see text below about possible appending of .pmc
@@ -6800,16 +6806,20 @@ F<.pmc> extension. If this file is found, it will be loaded in place of
68006806any file ending in a F<.pm> extension. This applies to both the explicit
68016807C<require "Foo/Bar.pm";> form and the C<require Foo::Bar;> form.
68026808
6803- You can also insert hooks into the import facility by putting Perl code
6804- directly into the L<C<@INC>|perlvar/@INC> array. There are three forms
6805- of hooks: subroutine references, array references, and blessed objects.
6809+ You can also insert hooks into the import facility by putting Perl
6810+ coderefs or objects directly into the L<C<@INC>|perlvar/@INC> array.
6811+ There are two types of hooks, INC filters, and INCDIR hooks, and there
6812+ are three forms of representing a hook: subroutine references, array
6813+ references, and blessed objects.
68066814
68076815Subroutine references are the simplest case. When the inclusion system
6808- walks through L<C<@INC>|perlvar/@INC> and encounters a subroutine, this
6809- subroutine gets called with two parameters, the first a reference to
6810- itself, and the second the name of the file to be included (e.g.,
6811- F<Foo/Bar.pm>). The subroutine should return either nothing or else a
6812- list of up to four values in the following order:
6816+ walks through L<C<@INC>|perlvar/@INC> and encounters a subroutine, unless
6817+ this subroutine is blessed and supports an INCDIR hook this
6818+ subroutine will be assumed to be an INC hook will be called with two
6819+ parameters, the first a reference to itself, and the second the name of
6820+ the file to be included (e.g., F<Foo/Bar.pm>). The subroutine should
6821+ return either nothing or else a list of up to four values in the
6822+ following order:
68136823
68146824=over
68156825
@@ -6848,10 +6858,37 @@ Note that this filehandle must be a real filehandle (strictly a typeglob
68486858or reference to a typeglob, whether blessed or unblessed); tied filehandles
68496859will be ignored and processing will stop there.
68506860
6851- If the hook is an array reference, its first element must be a subroutine
6852- reference. This subroutine is called as above, but the first parameter is
6853- the array reference. This lets you indirectly pass arguments to
6854- the subroutine.
6861+ If the hook is an object, it should provide an C<INC> or C<INCDIR>
6862+ method that will be called as above, the first parameter being the
6863+ object itself. If it does not provide either method, and the object is
6864+ not CODE ref then an exception will be thrown, otherwise it will simply
6865+ be executed like an unblessed CODE ref would. Note that you must fully
6866+ qualify the method name when you declare an C<INC> sub (unlike the
6867+ C<INCDIR> sub), as the unqualified symbol C<INC> is always forced into
6868+ package C<main>. Here is a typical code layout for an C<INC> hook:
6869+
6870+ # In Foo.pm
6871+ package Foo;
6872+ sub new { ... }
6873+ sub Foo::INC {
6874+ my ($self, $filename) = @_;
6875+ ...
6876+ }
6877+
6878+ # In the main program
6879+ push @INC, Foo->new(...);
6880+
6881+ If the hook is an array reference, its first element must be a
6882+ subroutine reference or an object as described above. When the first
6883+ element is an object that supports an C<INC> or C<INCDIR> method then
6884+ the method will be called with the object as the first argument, the
6885+ filename requested as the second, and the hook array reference as the
6886+ the third. When the first element is a subroutine then it will be
6887+ called with the array as the first argument, and the filename as the
6888+ second, no third parameter will be passed in. In both forms you can
6889+ modify the contents of the array to provide state between calls, or
6890+ whatever you like.
6891+
68556892
68566893In other words, you can write:
68576894
@@ -6871,24 +6908,66 @@ or:
68716908 ...
68726909 }
68736910
6874- If the hook is an object, it must provide an C<INC> method that will be
6875- called as above, the first parameter being the object itself. (Note that
6876- you must fully qualify the sub's name, as unqualified C<INC> is always forced
6877- into package C<main>.) Here is a typical code layout:
6911+ or:
68786912
6879- # In Foo.pm
6880- package Foo;
6881- sub new { ... }
6882- sub Foo::INC {
6883- my ($self, $filename) = @_;
6913+ push @INC, [ HookObj->new(), $x, $y, ... ];
6914+ sub HookObj::INC {
6915+ my ($self, $filename, $arrayref)= @_;
6916+ my (undef, @parameters) = @$arrayref;
68846917 ...
68856918 }
68866919
6887- # In the main program
6888- push @INC, Foo->new(...);
6889-
68906920These hooks are also permitted to set the L<C<%INC>|perlvar/%INC> entry
68916921corresponding to the files they have loaded. See L<perlvar/%INC>.
6922+ Should an C<INC> hook not do this then perl will set the C<%INC> entry
6923+ to be the hook reference itself.
6924+
6925+ A hook may also be used to rewrite the C<@INC> array. While this might
6926+ sound strange, there are situations where it can be very useful to do
6927+ this. Such hooks usually just return undef and do not mix filtering and
6928+ C<@INC> modifications. While in older versions of perl having a hook
6929+ modify C<@INC> was fraught with issues and could even result in
6930+ segfaults or assert failures, as of 5.37.7 the logic has been made much
6931+ more robust and the hook now has control over the loop iteration if it
6932+ wishes to do so.
6933+
6934+ There is a now a facility to control the iterator for the C<@INC> array
6935+ traversal that is performed during require. The C<$INC> variable will be
6936+ initialized with the index of the currently executing hook. Once the
6937+ hook returns the next slot in C<@INC> that will be checked will be the
6938+ integer successor of value in C<$INC> (or -1 if it is undef). For example
6939+ the following code
6940+
6941+ push @INC, sub {
6942+ splice @INC, $INC, 1; # remove this hook from @INC
6943+ unshift @INC, sub { warn "A" };
6944+ undef $INC; # reset the $INC iterator so we
6945+ # execute the newly installed sub
6946+ # immediately.
6947+ };
6948+
6949+ would install a sub into C<@INC> that when executed as a hook (by for
6950+ instance a require of a file that does not exist), the hook will splice
6951+ itself out of C<@INC>, and add a new sub to the front that will warn
6952+ whenever someone does a require operation that requires an C<@INC>
6953+ search, and then immediately execute that hook.
6954+
6955+ Prior to 5.37.7, there was no way to cause perl to use the newly
6956+ installed hook immediately, or to inspect any changed items in C<@INC> to
6957+ the left of the iterator, and so the warning would only be generated on
6958+ the second call to require. In more recent perl the presence of the last
6959+ statement which undefines C<$INC> will cause perl to restart the
6960+ traversal of the C<@INC> array at the beginning and execute the newly
6961+ installed sub immediately.
6962+
6963+ Whatever value C<$INC> held, if any, will be restored at the end of the
6964+ require. Any changes made to C<$INC> during the lifetime of the hook
6965+ will be unrolled after the hook exits, and its value only has meaning
6966+ immediately after execution of the hook, thus setting C<$INC> to some
6967+ value prior to executing a C<require> will have no effect on how the
6968+ require executes at all.
6969+
6970+ As of 5.37.7 C<@INC> values of undef will be silently ignored.
68926971
68936972For a yet-more-powerful import facility, see
68946973L<C<use>|/use Module VERSION LIST> and L<perlmod>.
0 commit comments