A few years back, method chaining got to be all the rage, and now it's common. I'm not sure it's a good thing, though, because you only gain a little syntactic clarity, but at the cost of losing the return value of a function.

In a functional programming style, you write code like this:

a = f(g(h(x)));

Or you write it Lisp style:

(set a (f (g (h x) ) ) )

Pretty much the same thing, and it means the return value is the input to the next function.

The Unix shell parallel is pipes:

cat a | sort | uniq | more

The output of one command becomes the input of the next.

In method chaining, there's a big difference: each method call returns a reference to the object, and thus the object's context:

$f = new Foo();
$f->set_a(10)->set_b(30);

Fine. both set_a and set_b return $f, so you can make another method call on the object.

This seems okay when all you're doing is setting, but suppose you wanted to change the type of the object:

$f = new Foo();
$f->to_string()->split(',')->apply(function ($a) {echo $a;});

I'm not sure I could do that in PHP, but, that would be, I think, a better way to use that return value.

Of course, setters and getters are different beasts. The setters can be chained. The getters all return values that are not the object itself.

What about appending an object:

$f = new Foo();
$f->append($x);

The append() method should probably return $f.

What about deleting an object:

$f = new Foo();
$f->delete_like('x*');

The delete_like() method should probably return $f.

Perhaps my suspicions about method chaining are all wrong.