From: dblack@...
Date: 2006-12-14T03:35:50+09:00
Subject: Re: map taking an argument (was: Re: join_with)

Hi --

I screwed up my procmailrc briefly and lost a couple of messages.  So
I'm answering myself but really answering Ara, whose message I got
from Google groups.

Ara wrote:

> On Thu, 14 Dec 2006, dblack@wobblini.net wrote:

> > Hi --
> >
> > There was an RCR a while back, rejected by Matz, that asked for:
> >
> >  enum.map(:m)
> >
> > to be the same as:
> >
> >  enum.map {|e| e.m }
> >
> > It looks like Ruby >= 1.9 has this:
> >
> >  enum.map(&:m)
> >
> > which strikes me as the same thing, functionally, but visually noisier
> > and semantically more obscure.
> >
> > I'm just wondering what the rationale is for rejecting the simple
> > version and introducing the less simple one.
> 
> i think that makes good sense considering ruby's pattern of not
> auto-magically munge aruements: we all agree that it's a good thing
> that this does not work
>
>    "40" + 2
> 
> the e.map(:m) is exactly the equivalent of that: it says "by the
> way, if you pass me a symbol object i'll auto-magically convert that
> to a method call on the object.

I don't see a similarity.  It's not a conversion to a method; you
couldn't replace the symbol with a method object.  It's just a
decision to have the argument have that meaning.  It may even be more
circuitous, in a sense, than converting 2 to a string, but I don't
think it's the same at all.

> now, e.map(&:m), while functionally similar, is completely different.
> no magic casting is going on, it's just that symbols have aquired a
> 'to_proc' method that returns a block calling that method on any
> object.  this concept actually has nothing to do with map at all:
> it's othogonal and totally generic, for example
>
>    %w[ a b c ].each &:display
>
> works as expected.  so does this
>
>    %w[ c b c ].sort_by &:upcase
> 
> so by simply adding Symbol#to_proc a generic mechanism has been
> created which
> can augment potentially any method that takes a block and yields a
> value.
> 
> given that this will work all over the place, it's doubtfull that it
> will be more obsure than a special case for map, since people will
> use the idiom all over the place.

Maybe that's what I'm afraid of.  I find it obscure and ugly.


David

-- 
Q. What's a good holiday present for the serious Rails developer?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
    aka The Ruby book for Rails developers!
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)