Not that the how hasn't been answered, but just a side related comment if you're doing this for anything other than maybe pedagogical reasons:
Unless you're trying to modify the module for some reason you probably shouldn't go monkeying around in a random module's internals and introduce dependencies on things that aren't specified in its documentation. What's documented is the public API and you can (mostly, usually :) count on that interface not changing, or if it does that any changes will (probably) be noted therein the subsequent versions.
If you go and tie your code to something which isn't documented you're just asking for trouble because you may then be dependent on something the author considers a trivial implementation detail. When they change it out from under you without making any note of it your code's going to be broked and it's going to take effort to figure out why (e.g. you upgrade Foo::Blorp and the module tests all passed, but your code now can't access $Foo::Blorp::vreemflitzel any more).
The cake is a lie.
The cake is a lie.
The cake is a lie.
In reply to Re: How do I check all the variables, subroutines etc in a Perl Module?
by Fletch
in thread How do I check all the variables, subroutines etc in a Perl Module?
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |