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
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.
Regarding #2, it sounds like AnyLoader.pm or AutoUse.pm or something
else, along with some better hooks or even just a friendlier XS
substitute (Inline?), would probably fit the bill. Then there could be
sub-classes that handled Class::Contract type stuff, service registries,
and anything else that people wanted.
I think that Format.pm and Socket.pm fit in category #2. If anything,
this discussion has convinced me that trying to autoload these by
default is *not* a good idea. People already have to "use FileHandle"
and "use Fcntl" for certain functionality. A few more modules doesn't
stike me as terrible, especially if it will result in Perl being faster
(and by "faster" I mean faster than if it had to read the
"autoload.conf" file at every startup, not necessarily faster than if
these were in CORE).
Plus, some people might prefer Text::Autoformat to Format.pm anyways, so
why bother adding overhead to check for format() on every startup if a
user doesn't really care? And then there's the idea of "use Perl5" to
handle the transition, p52p6, etc.
> >I would assume that 'use' would be done before 'autouse', so any 'use
> >lib' statements would already be taken into account? I'm probably
> >missing something super-obvious, so please point it out if so.
>
> Doubt it. They'll likely be done as they're encountered, though that does
> mean that your libs will be set before you need them, unless you order your
> source really strangely.
Yep, that's actually basically what I meant. Thanks for clarifying.
-Nate