Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
- Optionally avoid AutoLoader
Re: Optionally avoid AutoLoader
The %INC hash is updated before the required file starts compiling. I'm
not clear exactly when you will be defining this alternative AUTOLOAD:
in fact, it sounds like you don't want to redefine AUTOLOAD at all, you
just want to preload all the autoloadable subs. If the subs are defined
AUTOLOAD won't get called at all.
String eval is considered to be within the lexical scope of the code
that calls it, so it will inherit pragma settings from the outside. You
want to be careful about this: if your eval is in the scope of, say,
'feature', that will be applied to the evaled code. It will also see any
lexicals which are visible outside the eval, which may make for some
rather strange bugs if you pick one up accidentally.
It might be worth using a trick I've used in the past, and using the
coderef-in-@INC hook to let you load the code with require rather than
eval. Required code gets a fresh lexical scope, so there is less chance
for things to go wrong: if you want an example of how to do this, I've
probably got one lying around somewhere. You will also probably want to
use #line to make the line numbers and filenames come out right: see the
very end of perlsyn.
(I was incorrect about what appears in %INC: the value in %INC is the
actual coderef or object that was in @INC. The "/loader/0x..." name is
what will appear in stack traces and the like, unless it was overridden
with a #line directive.)
There's nothing really to understand: under some (slightly obscure)
circumstances, you will find values in %INC which aren't valid filenames
(in fact, which aren't strings at all). You just need to make sure your
code doesn't do anything stupid in that case; if you really wanted to
you could call the coderef or invoke the object's ->INC method to reread
the file, but it probably isn't worth it. See perldoc -f require for all
This only usually applies when, say, a program has been packed with PAR,
or something else is being clever about fetching module files from
somewhere unusual, so it shouldn't be a major problem in practice.
- » Using symbolic references to invoke package methods - good or bad practice?
- — Previous thread in » PERL Discussions