One of the things you can do with an @INC hook is signal the interpreter to keep looking for a file on disk, or fake out that you've got a module that you don't really have.

I've found that most of the time I want my @INC hooks to live at $INC[0] or at $INC-1, depending on whether I'm writing an observer or a fallback hook. Simply unshifting (or pushing) your hook where you want it isn't sufficient, since other modules you load can and will tamper with the ordering of things in @INC. "use lib", for example, will push to @INC, and if your hook depends on being the last most entry in @INC, then now you're broken. Tieing @INC is the only way I've found to ensure my hooks stay where I think they belong.

I wrote Array::Sticky::INC to ensure @INC hooks stay where they belong; you might have a look at that module, and some of the documentation I wrote up as part of it, for a bit more detail and use cases.

L*

@INC.*\\& · CPAN->grep -> lib::http, Module::AutoLoad, persona

use.lib.*\\& · CPAN->grep -> Devel::Hide

So the basic use case is the same as for Filter::Simple

Thanks, cpan-grep is a clever approach.

Using the word hook instead of \\& gives additional hits.

> So the basic use case is the same as for Filter::Simple

Altering existing modules is one use case.

Another is loading existing modules from other sources like usb-sticks or via http.

I wonder if there is a use case where a module's source is generated on the fly.

Cheers Rolf
_{(addicted to the Perl Programming Language and ☆☆☆☆ :)
Je suis Charlie!}