Dan Sugalski wrote:
>
> >Regarding #1, if there's no need to make it extensible by users, why
> >have a file at all? This shouldn't change after Perl is built, right?
> >And all of the stuff that's going to be "autoloaded" in this way will be
> >included in the core dist, right? Sounds like some #defines would work
> >better for this.
>
> But we may well add in things after perl has been built, or upgrade modules
> that come with perl and do this after the fact. (If, say, someone redoes
> Socket to handle IPv6, it'd be nice to be able to upgrade perl's socket
> handling code without having to actually upgrade perl, assuming an
> upgrade's even available)
But, the problem I see here is that now we're back to loading user-level
modules. See if I'm making any sense here. Basically, the example you
describe boils down to writing Socket::IPv6 or fixing Socket.pm,
correct?
In this case, if we forget about the autoloading for just a second, then
the problem simply boils down to the Perl 5 construct:
use Socket;
and assuming that the user has upgraded Socket.pm properly, the new code
is automatically imported. So, the autoloading thing, really, is
designed to get around a user having to use "use", know what module
something is in, etc. A user doesn't have to care about Format.pm
because it's autoloaded. And the autoloading keeps it modular and
upgradeable, as you point out.
But regarding the upgrade issue, what if I use CPAN.pm to add the new
Socket.pm into ~/perl/lib, because my sysadmin won't? How does the
autoloader handle this? If there's one config file, how can I specify
different conditions? What if I want to distribute my script, and want
the convenience of the autoloader, but also want to ensure that
Socket.pm supports IPv6 because I need Socket.pm version 2.03? How can I
do this?
At this point, I think we should take a look at something like
AnyLoader, and what would be required to make it reasonably extensible
so that conditions, versions, import lists, etc can be specified. And I
think that at the end of this road lies something like AnyLoader +
Damian's proposed JAPH syntax, which is easily extensible.
I'm not trying to harp, I'm just trying to clarify, because I think
there's some fine-line distinctions that are important to this
discussion. What's the likely difference between ops and subs in Perl 6?
Is the goal "subs as fast as ops" still? In this case, does autoloading
an op in post-build have any benefit over autoloading a module in
post-build?
Again, let me stress that I really like the autoloading concept (I wrote
RFC 153 :-), but I think that the current ideas might be too limiting,
and may be addressing the wrong issues. Fast is good, and faster is way
better, so maybe autoloading shouldn't be default-worthy and should be
pragma-induced?
# Allow autoloading of any needed functions
use autoload qw(:all);
Then any additional overhead for parsing a more extensible config file
could be justified.
-Nate
