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

> Hi --
>
> On Wed, 6 Dec 2006, Martin DeMello wrote:
>
>> While golfing with the hex_ip thread, I realised that map takes no
>> argument, and join takes no block, leaving a vacuum for a combined
>> method:
>
> Your point about map re-raised a question that was in my head
> recently.
>
> 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.
>
>
> David

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.

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.

regards.

-a
-- 
if you find yourself slandering anybody, first imagine that your mouth is
filled with excrement.  it will break you of the habit quickly enough. - the
dalai lama