in reply to chaining method calls

Thanks to jeffa for explaining what the heck was going on -- until I read his node (the last on this page) I had no idea what you folks were talking about (again).

This is very cool, but it would also make debugging a bit of a challenge -- who wants to re-write code to catch an intermediate result?

While it is a little longer to say .. 

my $soap = uri('http://www.soaplite.com/Temperatures');
$soap->proxy('http://services.soaplite.com/temper.cgi');
$soap->f2c(32);
print $soap->result;

[download]

.. in terms of code maintenance that's much better (if I've translated that back correctly).

--t. alex
Life is short: get busy!

Replies are listed 'Best First'.
Re: Re: chaining method calls
by perrin (Chancellor) on Jun 12, 2003 at 18:04 UTC
    Thanks to jeffa for explaining what the heck was going on -- until I read his node (the last on this page) I had no idea what you folks were talking about (again).

    You just put your finger on what I don't like about this: it is not a common idiom. It confuses many people, even those who know perl well.

[reply]

      You just put your finger on what I don't like about this: it is not a common idiom.

      I keep seeing people say this idiom isn't common, which to me is a bit of a suprise as Data::Dumper employs this idiom, and even has 

      $d->Purity(1)->Terse(1)->Deepcopy(1);

      [download]

      in its synopsis, and

      The method forms return the object itself when called with arguments, so that they can be chained together nicely.

      in its method documentation. As Data::Dumper is one of my earliest memories of Perl (the wonder of watching that data structure stream down the screen!) I have always assumed this idiom was common place. (And shouldnt every Perl hacker past their first script know about Data::Dumper? The thought of hacking perl without it make me cringe.)

      Having said that, Ive employed the idiom myself on occasion, and on occasion found myself removing it afterwards. I think its an optimise-for-the-common-usage judgement call when designing a classes interface. If its likely that you would want to set many attributes of an object at once, without being concerned with the new or old value then it can be convenient to provide chaining. OTOH, sometimes I find that having set accessors return the new value (or the old value sometimes) can be a big code simplification, so sometimes I go that way. I do whatever "feels" appropriate for how I envisage myself and others using the routines in question. So long as the behaviour is documented I dont see any problem with any of the common approaches, nor with using any mixture of them in a single module, so long as the end result is reasonably intuitive.


      ---
      demerphq

      <Elian> And I do take a kind of perverse pleasure in having an OO assembly language...
[reply]
[d/l]
[select]

In Section Meditations