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.

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