From: Trans <transfire@...>
Date: 2006-09-30T00:55:16+09:00
Subject: Re: New magical version of Symbol.to_proc


Charles O Nutter wrote:
> On 9/28/06, Dr Nic <drnicwilliams@gmail.com> wrote:
> > I like this idea too - something that allows you to pick which iterator
> > method to use (that is: select, each, map)
> >
> > Implementable syntax might be:
> >
> > %w{the meaning of 42}.map_length
>
> FWIW I really prefer the magic underscore over anything else.
>
> The pluralization thing has too much potential for collision and looks
> jarring (to_as looks to me like "to" "as", which doesn't make any
> sense; then again I'm not a fan of programmatic pluralization for any
> reason, since it's very western-language-centric and far from
> foolproof (moose? virus? fish?)).

You are right there. Pluralization is really going overboard, besides
the exceptions it creates a great deal of computational overhead. It
seems great on the surface, but in the end it is simply is not worth
the effort. Although it can seem odd for the English speaker at times,
Ruby's general favoring of the singular is a very good thing. And this
is one area in which I feel Rails has been unhelpful.

> The magic dot has a potential to create scads more objects to handle
> the adapting. With a magic dot, list.map.to_i necessarily has to
> create some adapter object for the call to map so there's a receiver
> for to_i where no object was required before. Unless Ruby is adding a
> pretty powerful GC in the future, perhaps we should avoid adding tons
> of transient objects just for the magic dot.

Actually this is largely mitigated. Best practice is to cache the
adapter object. So for example Enumerable#every:

  def every
    @_functor_every ||= Functor.new do |op,*args|
      self.collect{ |a| a.send(op,*args) }
    end
  end

This is something not often shown in examples and admittedly may not
make it into first editions of such functions in practice, but
utlimately it gets incorporated and makes a huge difference in the over
head you mention.

> The magic underscore has far less potential to cause a collision and
> requires no intermediate objects to be created. And as others have
> mentioned, it's been proven to look and feel really nice by
> ActiveRecord.

I disagree. "Magic underscore"[1] is either a function of
method_missing or dynamic method creation. There is acually more
potential for name collision in these cases. IN fact that is one of the
uses of the magic dot, to create namespaces. Also care must be taken to
propogte method_missing through the class heirarchy so as not to step
on other people's magic toes. And dynamic method creation adds a lot of
additional methods to a class that Ruby must sort through when
dispatching a call. It certainly looks nice, and I'm in no way agasint
it's use. But there are tradoffs to be considered, and one should apply
that techinique that works best to the need at hand.

[1]FYI, "magic underscore" isn't an a good name b/c we're really just
talking about dynamic method names. These can be anything and do not
neccessarly need an underscore.

T.