Can I load a package's Autoload-able subs without executing them?

[w.c.humann]

I want to be able to really load all subs in a given package,
including all load-on-demand subs. I don't want to execute them in the
process. Ideally it should work irrespective of the mechanism (e.g.
AutoLoader, SelfLoader, load-pragma) used inside the module. But the
next best thing would be a solution just for "use AutoLoader"-modules.

I could manually look for ".al"-files and require them but that's not
very elegant as it uses knowledge about internals I shouldn't need to
have.

Why do I want to do this? I'm deriving from Devel::TraceCalls to see
what's going on inside my Perl/Tk application. For a while I wondered
why some functions never got traced. Well, when the tracer is
instantiated they are not there -- they are autoloaded later -- so the
tracer can't wrap them...

Thanks,
Wolfram

 

[anno4000]

I want to be able to really load all subs in a given package,
including all load-on-demand subs. I don't want to execute them in the
process. Ideally it should work irrespective of the mechanism (e.g.
AutoLoader, SelfLoader, load-pragma) used inside the module. But the
next best thing would be a solution just for "use AutoLoader"-modules.

I could manually look for ".al"-files and require them but that's not
very elegant as it uses knowledge about internals I shouldn't need to
have.

That would only cover cases where an external *.al file is used.

Why do I want to do this? I'm deriving from Devel::TraceCalls to see
what's going on inside my Perl/Tk application. For a while I wondered
why some functions never got traced. Well, when the tracer is
instantiated they are not there -- they are autoloaded later -- so the
tracer can't wrap them...

Programmers frequently would like to do that. Yours is as good a reason
as any.

The sad truth is that it can't be done. All the mechanisms you mention
are based on the behavior of the AUTOLOAD routine, which is called
before the interpreter gives up on a sub name. This is described
in perlsub. One fact is that AUTOLOAD doesn't even have to define
the function it is called to "autoload". It could perform the
function directly, depending on the sub name, and never leave a trace.

Anno

 

[Ben Morrow]

Quoth (e-mail address removed)-berlin.de:

Programmers frequently would like to do that. Yours is as good a reason
as any.

The sad truth is that it can't be done. All the mechanisms you mention
are based on the behavior of the AUTOLOAD routine, which is called
before the interpreter gives up on a sub name. This is described
in perlsub. One fact is that AUTOLOAD doesn't even have to define
the function it is called to "autoload". It could perform the
function directly, depending on the sub name, and never leave a trace.

One solution would be to have your tracer install a trace on AUTOLOAD as
well, and handle it specially (noting the value of $AUTOLOAD, for
instance; and probably trying to install a trace on the autoloaded sub,
if it exists, after AUTOLOAD returns). Note that your problem here isn't
strictly autoloading: it's the fact that Perl allows you to modify the
symbol table at runtime. And there's no way around that: if a program
randomly inserts a new sub into the symbol table, there's no way for you
to find out.

Ben

 

[w.c.humann]

One solution would be to have your tracer install a trace on AUTOLOAD as
well, and handle it specially (noting the value of $AUTOLOAD, for
instance; and probably trying to install a trace on the autoloaded sub,
if it exists, after AUTOLOAD returns). Note that your problem here isn't
strictly autoloading: it's the fact that Perl allows you to modify the
symbol table at runtime. And there's no way around that: if a program
randomly inserts a new sub into the symbol table, there's no way for you
to find out.

That's a nice idea but with a few problems:
- It involves a lot of bookkeeping. I need to remember every category
of
things that a user wanted to trace and see if a matching autoload
comes around.
- It prevent me from notifying the user of misspelled function names.
If
the user wants to trace "Tk::FocusNext" (which really should be
spelled
"Tk::focusNext") I can't tell him there's no such function, cause it
might be autoloaded any time...

(I might still give it a try...)

Wolfram