in reply to Re: Re: chaining method calls
in thread chaining method calls

My opinion is that cascading is an idiom that doesn't translate well into Perl. Without a special syntax to designate a cascade, a simulated cascade is indistinguishable from a gross violation of the Law of Demeter.

That's an interesting point, and the most convincing one I've come across against the idiom. I can see how a maintainence coder might see a cascade and have it look like a ghastly exposure of internals ripe for refactoring.

That said, it's not a problem I've ever come across. Probably because that by the time you're looking at the code you already have an idea of what methods are associated with what objects, so you can mentally parse out cascades from other code.

The fact that I try not to write objects that flagrently violate the LoD probably helps too :-)

(I wonder if Perl6 will have an explicit syntax? If not we could always make one up.)

I still find:

$my_object_variable->foo($x)->bar($y)->ni($z);

[download]

clear, and preferable to:

$my_object_variable->foo($x)
$my_object_variable->bar($y)
$my_object_variable->ni($z)

# or

for ($my_object_variable) {
  $_->foo($x); 
  $_->bar($y);
  $_->ni($z);
};

[download]

To me the former is succinct and obscures the mainline less. Probably too much Smalltalk at an early age :-)

Replies are listed 'Best First'.
Re: Re^3: chaining method calls
by perrin (Chancellor) on Jun 12, 2003 at 20:24 UTC 
    $my_object_variable->foo($x)->bar($y)->ni($z);

    [download]
    The trouble is, that sort of construct already has a meaning and this isn't it. Chaining methods on different objects is common. Like this, for example: 
    $car->wheels()->turn('right');

    [download]
    That kind of thing is common on most OO languages, and it's what I expect when I see chained method calls. This "return yourself" business foils my expectations.
[reply]
[d/l]
[select]

      The way I see this idiom used is fairly consistent. $self is only returned for mutators (upon success). Thus, the expectations are clear: mutators always return $self upon success and accessors never return $self. If accessors return an object, it's known the the object is not the calling object. That, actually, is yet another reason why I prefer to have separate accessors and mutators ('name' or 'get_name' vs. 'set_name'). This clear distinction makes the expectations clear. And again, if you don't like the chained features, you don't have to use it. Chained method calls are usually an extra feature as opposed to the replacement of a feature that is already used.

      I also note that you object to this idiom because it's not common. If it were a bad idiom, I would consider this to be a benefit. If it's a good idiom, then that's a negative. Which way it falls is still kind of up in the air, though. I'm glad you raised the issue.

      Cheers,
      Ovid

      New address of my CGI Course.
      Silence is Evil (feel free to copy and distribute widely - note copyright text)

[reply]
        The way I see this idiom used is fairly consistent. $self is only returned for mutators (upon success). Thus, the expectations are clear: mutators always return $self upon success and accessors never return $self.

        Consistent or not, because there's no first-class support for cascading in Perl, the reader is forced to do a lot of digging to distinguish a simulated cascade from sloppy coupling. Basically, to be sure, you have have to read all of the methods. In a first-class cascade (like those supported by Smalltalk) a surface read is sufficient.

[reply]
Re: Re^3: chaining method calls
by BUU (Prior) on Jun 12, 2003 at 17:38 UTC
    >> wonder if Perl6 will have an explicit syntax? It's my understanding that perl6 will change the method call operator to operate on the current blocks default variable ($_ is always the default var in perl5). Which allows you write things like: 
    sub foo
{
 my $bar=new Obj, is default; #ok, I don't remember the exact syntax b
+ut I'm sure you get what I mean
 .foo();
 .baz();
 .qux();
}

    [download]
[reply]
[d/l]

In Section Meditations