Re: Symbol table globbing from object refs
by PodMaster (Abbot) on Nov 29, 2003 at 11:05 UTC
|
Things like evaluating @ISA by hand *snip* seem so excessive that I reckoned someone must have thought of something.
Yes, examine @ISA (that's one of the reasons @ISA exists).
use Scalar::Util qw{ blessed };
use Module::Info;
use Data::Dumper;
use IO::File;
die Dumper( Module::Info->new_from_module( blessed( IO::File->new() ) ) );
update: also worth reading up on are Devel::ModInfo and Devel::Symdump.
| MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!" | | I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README). | | ** The third rule of perl club is a statement of fact: pod is sexy. |
| [reply] |
|
|
| [reply] |
|
|
->can() doesn't handle AUTOLOADed methods, FYI.
| [reply] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
But @ISA is usually lexical, which means i have to peek into it somehow. Ugly.
@ISA is also very flexible - code refs and such. I'm not sure I want to implement something that's already been done - emulation is never 100%
Morever, I can't guarantee this has a module, i'm expecting weird objects (classless ones, and so forth), so Module::Info doesn't work. At least not unless I use it on an opened scalar ref, containing B::Deparse's output. Very ugly.
Last but not least, this is too resource intensive for such a simple job, IMHO.
| [reply] |
|
|
But @ISA is usually lexical, which means i have to peek into it somehow.
Say what?!? If @ISA isn't a global/package variable, inheritance won't work. So it's never a lexical.
| [reply] |
|
|
So what?
You requirements/expectations are completely unrealistic.
| [reply] |
|
|
Re: Symbol table globbing from object refs
by broquaint (Abbot) on Nov 29, 2003 at 15:23 UTC
|
This should give you a list of all functions available to a given object
use Class::ISA;
use Devel::Symdump;
## you may want to use Scalar::Util's blessed()
my $pkg = ref $obj;
Devel::Symdump->functions(
Class::ISA::super_path($pkg), $pkg
);
See. Class::ISA and Devel::Symdump for more info.
| [reply] [d/l] |
|
|
This should give you a list of all functions available to a given object
I think some Autoloaded functions (such as accessors) may be missed, unless they have been used before. I played with this idea from Conway's book Object Oriented Perl, p91, pp114-7 a few years ago.
However, a user-centered design should document the public ones, and make their names available through some mechanism. What that mechanism should be, I'm not certain. I only raise the point to ask if this hole has a cover.
Update: I meant to ask "What is the convention for objects to communicate their method names to the outside world, given that Autoload may be employed?"
Update 2: Page numbers added.
-QM
--
Quantum Mechanics: The dreams stuff is made of
| [reply] |
|
|
I think some Autoloaded functions (such as accessors) may be missed
Indeed, since an AUTOLOADed subroutine can be almost anything they're more or less impossible to test for. But this is also basically the same situation for any run-time generated subroutines, so any attempts at getting all available methods naively can only be so effective.
| [reply] |
|
|
Ideally all AUTOLOADable methods will be declared:
sub mymethod1;
sub mymethod2;
...
In practice, its not always done. | [reply] [d/l] |