In a previous posting, I speculated that a future version of Perl could use a general mechanism to allow module management to be provided via Perl code, as opposed to some specific module management ability itself.

I continue that line of thought with a specific suggestion. How about a mechanism similar to the way "overloaded" constants work. That is not really overloading, but uses the same syntax to enable and is often needed/used when overloaded operators are present too, so it's not too far afield. This idea is similar to "overloaded" constants, but doesn't really sound like overloading. So I don't like the overload keyword here.

In an "overloaded" constant, a hook function is called to change the compiler's interpretation of what it just parsed. It is told what the compiler read (the source text), what the compiler thought it was, and context. It can return unchanged what the compiler thought it was in the first place, or can return something different.

So, how about "overloading" the argument of require in exactly the same way? The docs on require shows that the bulk of the work is locating the file, using search paths, knowing what's implied with a bareword class name, seeing if the file's already loaded, etc. Then it can call the more primitive do function with the resulting filename string.

So, how about allowing a hook to inspect the argument to require? It will be given the source text, the result of the built-in search and expansion (the filename it resolved or undef), and context to indicate whether it was a require or use, bareword or string or expression.

The hook function can, for example, return the built-in resolution unchanged except when it sees undef, in which case it locates and/or installs the module in some way, then returns the file name.

It would be good to expose the built-in logic to be called explicitly somehow, so that the function can re-call the original search process after changing @INC or adding files. Perhaps a CORE::xxx named function.

Another use would be to log what's actually used by a running program, or verifying signatures or against an approval list before loading.

It should also be possible to chain to the old function, so such logging wrappers can cooperate with other code. Perhaps the installation mechanism can return the existing hook, if any, so the new one can feel free to call that before, during, or after it's own work.

This feature, for purposes of auto-installing things, is best used in conjuction with the proposed Perl 6 feature of having implicit code included before every script. So, your copy of Perl can be set up to use a particular module manager and the scripts don't worry about it.

Anyone have similar or opposing thoughts? (anyone from p6p reading this?)

—John


In reply to The Future - Managing Modules by John M. Dlugosz

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":