At 12:54 PM 2/5/2001 -0800, Nathan Wiger wrote:
>Dan Sugalski wrote:
> >
> > > > The parser needs to have it in a standard system-wide place.
> > >
> > >Hmmm. I see what you mean, but why couldn't it be in @INC, first one
> > >wins? The file could be named AutoUse.pm or something.
> >
> > That strikes me as very much too high level a thing. I'm figuring there
> > will be no more than one file, and we may well go so far as to weld the
> > processed version of it into a shareable library that gets loaded in as
> > part of perl's startup.
>
>Yeah, I suspect there are two different ideas here trying to be
>satisfied by the same thing:
>
> 1. moving ops out of core
It's more being able to add in ops after the fact rather than move things
out of the core. (Though we may do the latter to prove the former)
> 2. autoloading user-level modules
>
>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)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
