2003-02-20

@INC hooks: there should be two kinds (IMO)

Seems like there are two different ways one might want to hook into @INC. The first is to provide an alternate location (see my Import Subversion example). This works fine by allowing coderefs in the @INC array.

But, it does seem to me that the other way one would want to hook into the import mechanism is to allow Perl do do its normal iteration over the @INC array, but to modify what it sees and/or how it deals with what it sees in those directories. For example, it normally looks for "$_/Some/Module/Path.pm" and is happy if it finds it. A module that lets the normal scanning process see "$_/Some/Module/Path.pmz" as a match (and associates an unzip filter with it for reading) seems like a distinct but good idea to me. There might even be some weirdness that allows one to see a "*.pm" directory with version-numbered files in it as a set of available versions for a module (compare with Brian Ingerson's use only module). This way, Perl would be happy to grab "$_/The/Finest.pm" as the module if it were a file, but if it were a directory, it would grab "$_/The/Finest.pm/undef.pm" (if there is no version) or "$_/The/Finest.pm/1.0.pm" (for version 1.0).

Again, this seems like it is a better fit for a what-to-do-when-visiting hook rather than a different-thingee-to-visit hook (which is what the current @INC coderef hook allows).

I submitted this as a comment to This Week on perl5-porters (10-16 February 2003) at use Perl.

No comments: