2007/11/13, Daniel DeLorme <dan-ml / dan42.com>:
> furtive.clown / gmail.com wrote:
> > I am a lone rubyist who went off the grid several years ago after
> > contributing a project on rubyforge, so perhaps *my* style is the
> > quirky one.  Still, in my mind the latter is sheer elegance compared
> > to the former.  I actually find it interesting that someone could
> > possibly disagree.  Do (1)-(3) make any sense, then?
>
> This kind of suggestion has been made several times in the past and,
> while I agree it looks elegant, I believe the issue is that "as" does
> not really /belong/ to the object on which it is called. It is a utility
> method. If you look at the base methods of Object you'll see that all of
> them have to do with the state of the object itself (except for the ugly
> exception of "display"). Semantically, a utility method has no business
> being part of the public interface of every object. A better solution
> would be with(expr){ |var| ... but that kills the elegance doesn't it? I
> sympathize, I really do. I have the same issue with my pet method "ergo"
>
> Lately I've been thinking that this could tie into Ara's concept of
> "pervasive" methods. If we define a pervasive method as a method that
> applies to all objects, then we could do something like
>      Pervasives.define do
>        def as
>          yield(self)
>        end
>      end
> Which could be called reliably as:
>      Pervasives.call(expr, :as){ |obj| ... }
> or less reliably through method_missing:
>      expr.as{ |obj| ... }
> leaving the Object methodspace unpolluted:
>      expr.methods.include?("as") #=> false
>
> no?

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

Cheers

robert

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