2007/11/13, Daniel DeLorme <dan-ml / dan42.com>:
> 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*?

Actually not, because I can do obj.public_methods(false). Also, if I
want to know what a particular method does I go to the documentation
anyway.

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

I had to wipe my glasses before I could spot it... :-)

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

I have to say I like #to_enum very much but I agree that there is the
issue of cluttering namespaces.  But IMHO no matter what you do (i.e.
explicit or implicit definition) the root problem does not go away
unless things like selector namespaces come into existence (i.e. a
particular view of a class / object in a context).  As long as that
does not exist there is always potential for name clashes no matter
what.

Cheers

robert

-- 
use.inject do |as, often| as.you_can - without end