I got email yesterday asking how to get a misused object to explain what methods it supports. Usually if you do $obj->fgsfds all you get is Can't locate object method "fgsfds" via package "Thing". After a use Help 'Thing' declaration, you get a list of methods supported by $obj, and which class each one is inherited from.

This may not be too useful by itself, but the implementation is very interesting, because it is short (only 30 lines), it requires a large number of less-well-known Perl features, and its use of those features is not too tricky. So studying the implementation of this module is a great way to learn a several advanced features of Perl at once.

I posted the code of the module with a detailed explanation of how it works.

In the past, I would have posted it here, but now that I have a blog, I posted it on my blog. But I thought some of you folks would be interested anyway, so I'm announcing it here.

Here it is. Enjoy!

  • Comment on automatically explains how to use misused objects

Replies are listed 'Best First'.
Re: automatically explains how to use misused objects
by lodin (Hermit) on Jan 12, 2008 at 08:09 UTC

    This is a nice module, and should be combined with Symbol::Sub::Approx to actively help (while issuing a warning). :-)

    There's a major problem with it though; the usual AUTOLOAD problem. Maybe another class in the inheritance tree has an AUTOLOAD to handle it. Then Help isn't really helping--rather the opposite. So you need to do

    use 5.010; use mro; # Make next::can available. use Sub::Name (); # Used to make next::can work # in anonymous subroutines. sub AUTOLOAD { my ($bottom_class, $method) = $AUTOLOAD =~ /(.*)::(.*)/s; # Note the /s above. It's legal to have # newlines in packages and symbols. my $next = Sub::Name::subname( $method => sub { $bottom_class->next::can } )->(); goto &$next if $next; ...; }
    By adding just two more statements in AUTOLOAD you illustrate a new Perl 5.10 feature. :-)

    But when moving onto Perl 5.10 your algorithm, while elegant and simple, becomes fragile due to the new method resolution orders (mro). Utilizing the lovely Devel::Symdump module by Andreas J. König you can replace

    my %known_method; my @classes = ($bottom_class); while (@classes) { my $class = shift @classes; next if $class eq __PACKAGE__; unshift @classes, @{"$class\::ISA"}; for my $name (keys %{"$class\::"}) { next unless defined &{"$class\::$name"}; $known_method{$name} ||= $class; } }
    use Devel::Symdump; my %known_method = reverse map /(.*)::(.*)/s, map Devel::Symdump::->functions($_), grep $_ ne __PACKAGE__, @{mro::get_linear_isa($class)} ;
    If you're on a pre 5.10 perl you can use Class::ISA's self_and_super_path. (I've contacted Mr Burke, the maintainer of Class::ISA, about updating it to use mro::get_linear_isa when it's available. Currently you need to figure out that yourself.)

    Of course, this makes it much less educational about the symbol table. :-)

    Update: I remembered that Help makes itself part of the inheritance tree, so I've removed the import of &subname to avoid it being inherited, and removed Help from %known_method.


Re: automatically explains how to use misused objects
by Jenda (Abbot) on Jan 12, 2008 at 01:21 UTC

    Neat. Neat except ... why the blog? I would expect it to have smaller audience and there's (AFAIK) no way to comment should one feel the need to do so. I know it's for you to decide, but I would rather see your (at least the Perl related) articles here :-)

    BTW, you'd probably catch me with that example from Clubbing someone to death with a loaded Uzi. I mean it's something I'd never expect anyone sane to do so it would take me some time to notice that this time someone did it. As I read the article I had to return to the first example after I read the one with those locations and finaly understood what the heck is going on. Thanks!

      Neat except ... why the blog?
      Well, my interests are a lot wider than Perl. And I like to post about them. And you folks would be unhappy if I posted my meditations on translations of Boccaccio here on Perlmonks. So I have a blog. And since I have a blog, it's the natural place to post when I write something that does happen to be about Perl. And if I wanted to post it here, I'd have to mark it up and format it a second time. So it's a lot easier to just post a reference to the blog.

      But if you want to mark it up and format it a second time and post it here, please be my guest.

      Having just seen an instance of iteration over a hash and getting values there on the basis of string equality tests against string constants from a co-worker (in VB.Net though, but the same argument applies of course)…

      … maybe it's more common among programmer who grew up in an environment with arrays being the most advanced dynamic data structure?

      On the other hand, I'm not sure what to make of the Club-Uzi-quote. The moment you get away from equality tests, because the particular key is only an abstraction of a wider class of strings which all have to refer to that particular value (e.g. case-insensitivity, internationalization, whatever) you are supposed to iterate over the keys (or the key-value-pairs) of the hash, aren't you?

        Depends. Most often not. Most often you are supposed to use a datastructure that supports that. If you can't use an Uzi, use something heavier. In case you want a case insensitive hash ... there are modules for that on CPAN, if you want some other definition of equality, you can do something similar to what those modules do and if you want to process all items whose keys match some more complex condition you should probably already be using a database. Even if it was just SQLite.

        Of course that sometimes looping though all the keys&values is the only solution. And using anything else would either be an overkill or would not help anything, the point is that before you start looping you should be sure you have to. Before you start banging your Uzi over someone's head, you should make sure the Uzi is not loaded. To save time and to make sure you do not shoot yourself in the foot :-)

A reply falls below the community's threshold of quality. You may see it by logging in.