Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re: Method chain object with easy syntax

by ihb (Deacon)
on Apr 16, 2005 at 21:54 UTC ( [id://448538]=note: print w/replies, xml ) Need Help??


in reply to Method chain object with easy syntax

I must be missing something. What's wrong with doing

$chain = sub { $_[0]->method1(@args1)->method2(@args2)->method3(@args3 +) };
? It doesn't suffer for the limitations you decribe. The only limitation as far as I can see is that it creates another scope if you use my() et al in the arguments, which is a bad idea anyway and is easily worked around.

Anyway... About your post:

If $method is a string with double colons, or a code reference, or a glob, then $object->$method is equivalent to &$method($object).

It's not true if it's a string with double colons or a glob. It searches the inheritance tree starting at the package specified in the string. The glob stringifies and for some reason '*Bar::foo' is also accepted.

#!/usr/bin/perl -wl use strict; no strict 'refs'; { package Foo; sub foo { 1 } } { package Bar; use base 'Foo'; } my $object = 'Bar'; # just the class name my $method = 'Bar::foo'; print "$object->$method ", eval { $object->$method } ? 'ok' : 'not o +k'; print "&$method($object) ", eval { &$method($object) } ? 'ok' : 'not o +k'; __END__ Bar->Bar::foo ok &Bar::foo(Bar) not ok
Btw, I think you're playing with fire when you do
for (@$chain) { ... }
since $chain @$chain may change during the loop. I'd feel much safer if you made a local copy of the array.

ihb

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

Replies are listed 'Best First'.
Re^2: Method chain object with easy syntax
by ambrus (Abbot) on Apr 19, 2005 at 20:38 UTC

    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) { ... }
    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) {
      to the not completely unusual construct
      while (@$chain) { my $pair = shift @$chain;
      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
      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; }

        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) ; } }

        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).

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://448538]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having a coffee break in the Monastery: (4)
As of 2024-04-26 05:54 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found