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?)

No, the hook could dynamically download and install locally, or copy from a network location, the files. It could also be used for things like verifying signatures, or reporting which modules and versions were actually used (before shipping).

Instead of die'ing when a use fails, it could automatically grab it from CPAN. Transparant use of distributed scripts!

Been there, done that. The following code is available
on CPAN, as the package The::Net. It "overloads"
require such that you can give it an
http or ftp URL, and it will
fetch the module for you using LWP.

-- Abigail

package The::Net;
#
# $Id: Net.pm,v 1.1 2001/04/29 04:22:11 abigail Exp abigail $
#
# $Log: Net.pm,v $
# Revision 1.1 2001/04/29 04:22:11 abigail
# Initial revision
#
#
use warnings 'all';
use strict;
use vars qw /$VERSION/;
($VERSION) =~ q $Revision: 1.1 $ =~ /([\d.]+)/;
push @INC => sub {
require LWP::Simple;
require IO::File;
require Fcntl;
my $url = pop;
return unless $url =~ m{^\w+://};
my $document = LWP::Simple::get ($url) or die "Failed to fetch $ur+l: $!\n";
my $fh = IO::File -> new_tmpfile or die "Failed to create temp fil+e: $!\n";
$fh -> print ($document) or die "Failed to print: $!\n";
$fh -> seek (0, Fcntl::SEEK_SET()) or die "Failed to seek: $!\n";
$fh;
};
1;
__END__
=head1 NAME
The::Net -- Use the Net to fetch your required modules.
=head1 SYNOPSIS
use The::Net;
require 'http://www.example.com/Module.pm';
=head1 DESCRIPTION
By using The::Net, you enable C<require> to fetch Modules using HTTP
or FTP, when given a URL as argument.
=head1 REVISION HISTORY
$Log: Net.pm,v $
Revision 1.1 2001/04/29 04:22:11 abigail
Initial revision
=head1 AUTHOR
This package was written by Abigail, abigail@foad.org.
=head1 COPYRIGHT and LICENSE
This package is copyright 2001 by Abigail.
Permission is hereby granted, free of charge, to any person obtaining +a
copy of this software and associated documentation files (the "Softwar+e"),
to deal in the Software without restriction, including without limitat+ion
the rights to use, copy, modify, merge, publish, distribute, sublicens+e,
and/or sell copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be include+d
in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRES+S OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILIT+Y,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHAL+L
THE AUTHOR BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT
OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.
=cut

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other