I don't know any reasons why this class can be useful in real life (i.e. production code). I wrote it more for learning perl then for actuall using it. Anyway, as I've mentioned, this technique could be useful for extending Switch or Quantum::Superpositions.

As for the semantics of $o->$m, you are right. It does inherit, and it does accept a stringified glob.

Btw, I think you're playing with fire when you do

for (@$chain) { ... }
[download]

since $chain may change during the loop. I'd feel much safer if you made a local copy of the array.

I disagree here. While the scalar $chain can change, it can point to a different array later, the scalar itself is fetched only once. The important point is that the contents of the array it points to at start doesn't change, and that is true.

Also, it is easy to verify that the implementation is reentrant with a code like this:

Update: In the simple case, sub { $_[0]->m1(@a1)->m2(@a2) } is of course simpler, but if you want to build a chain of methods without the length of it known in advance, then the sub solution can be more difficult.

the scalar itself is fetched only once

Is that guarenteed? If it is I almost withdraw my opinion. I say almost, because I still think it's unnecessary complicated (in that it uses a global as loop variable). If you change

for my $pair (@$chain) {
[download]

to the not completely unusual construct

while (@$chain) {
    my $pair = shift @$chain;
[download]

for whatever reason it'll demonstrate why I think this is playing with fire -- you have an extra thing to keep in mind two years later when you patch the code. As you say yourself

The important point is that the contents of the array it points to at start doesn't change

These's a general concensus that using globals like this is A Bad Thing, even if it's not such an obvious case. Not only do you have to remember that directly inside the loop not change @$chain, but you can't get the idea to assign to @$chain in &__Set_MethodChain__. That's a lot of unnecessary conditions just to not copy a presumably small array. If you copy the array you don't have anything extra to worry about and that might save yourself from future troubles. Indeed, the code works, I just get a bad feeling when I see it. :-)

if you want to build a chain of methods without the length of it known in advance, then the sub solution can be more difficult

You can easily compose new chains using other "sub chains", if that's what you're talking about.

#!/usr/bin/perl -wl

AUTOLOAD {
    print $::AUTOLOAD =~ /.*::(.*)/s;
    $_[0];
}

my $chain1 = sub { $_[0]->m2->m3 };
my $chain2 = sub { $_[0]->m1->$chain1->m4->m5 };

main::->$chain2;

__END__
m1
m2
m3
m4
m5
[download]

Maybe I misunderstood?

ihb

See perltoc if you don't know which perldoc to read!

I agree that iterating on @$chain isn't very clean code, because $chain is a global variable. You can of course make a copy of the array @$chain in the __Call_MethodChain__ function. The change is not difficult, the new sub is this:

sub __Call_MethodChain__ {
        my $r = $_[0];
        my @chain = @$chain;
        for my $pair (@chain) {
                my($method, $args) = @$pair{"method", "args"};
                $r = $r->$method(@$args);
        }
        $r;
}
[download]

Your point with the while loop is especially valid, because my code doesn't propagate context for a method chain call. The simplest version (the one with blessed subs) doesn't have this bug. The simplest way to fix this is a looped shift like this:

sub __Call_MethodChain__ {
        my $r = $_[0];
        my @chain = @$chain;
        for (;;) {
                my $pair = shift @chain;
                my($method, $args) = @$pair{"method", "args"};
                0 == @chain and
                        return $r->$method(@$args);
                $r = $r->$method(@$args) ;
        }
}
[download]

You are right, the straightforward solution can even handle dynamic building of method chains well, and it also doesn't have the bug I've mentioned above. I can still also say that this was just an experiment I made with perl (or even just some filthy trick to get some noderep).