Update {Please note the code at RFC: Class::Proxy::MethodChain that spun off of this snippet later and my eventual conclusion at Re: RFC: Class::Proxy::MethodChain. This code is far too elaborate an effort for something that can be had much easier; consider it an educational example, but don't go using it (in exactly this form). }

I've been doing some Gtk work lately, and if you've ever done so you'll know that code tends to turn into long runs of method calls against the same just instantiated widget, like:

You can imagine how bad it gets when there are 30 widgets distributed across four different containers, each object needing a dozen method calls to configure. With the following snippet, you can write this as

which I find much nicer. It lets you omit a lot of otherwise necessary temporary variables, and it also makes it clear - by way of nesting - which widgets are inserted where. In contrast, the flat structure requires you to search on the names of temporary widget variables to figure out how they all relate to each other.

It also has provision to deal with multilevel calls which are necessary for some objects:

but this requires that each of these configurator calls returns $self as the last step, which is frequently the case, although beginners don't understand why to do this because they've not seen this pattern before.
Even if it doesn't, I sometimes find myself simply chaining these calls using an alias:

Just use exceptions instead. Nothing wrong with wrapping a series of these things in an eval block to catch the exception.

I prefer exceptions when an action will likely work 95% of the time or more. That way, the testing doesn't interfere with my examination of the control flow, and you get to do nice tricks like a "return $self" chain.

I know about the first, but it wasn't possible here and also turns ugly when you have a multilevel call somewhere in that pile.

I was actually thinking the second is as good as I can do in this case. What I didn't like about topicalizing with a for in that case is that for one, I still have to mention the object for every method call, although at least it's only $_ now. And worse yet, I still need a temporary variable for every widget, even when it's a widget I don't care about having access to later (scrollbars often fall in this category f.ex).

By rearranging the program to use this snippet I managed to throw away about 4 out of 5 of my variables. That's more than a little win in clarity in my book.