From: Daniel DeLorme <dan-ml@...42.com>
Date: 2007-11-13T20:39:00+09:00
Subject: Re: Yielding an object and caring about the result: the cousin of Object#tap

Robert Klemme wrote:
> Hmm...  But this has the drawback that - since it's not defined on
> Object - it's difficult to be aware of this method.  Whether it's

It doesn't need to be explicitly defined on Object if you know that it's 
*pervasive* i.e. by definition available on all objects. Actually the 
same could be extended to all /methods|instance_var/ methods. Don't you 
ever do obj.methods and find yourself wishing all those were not there 
to clutter the bigger picture of what the object *does*?

> defined explicitly or called implicitly via method_missing all objects
> will properly respond to it.  I am not sure I understand the benefit
> of not explicitly defining it..

Indeed the behavior would be pretty much the same. The biggest 
difference is semantics I guess. Utility methods do not belong to the 
public interface, and therefore calling them through the public 
interface should be seen as mere synctatic sugar. A thin line to draw, I 
agree. Also the distinction between pseudo-public utility methods and 
true public methods may be a mere artifact of my mind, as 1.9 now 
includes tap, to_enum, and enum_for, which *definitely* classify as 
utility methods in my mind.

Daniel