Hi --

On Thu, 14 Dec 2006, Martin DeMello wrote:

> On 12/13/06, dblack / wobblini.net <dblack / wobblini.net> wrote:
>> 
>> 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.
>
> The 1.9 version is nicely orthogonal, though - it hasn't added
> anything to #map, since the Symbol#to_proc method is called eagerly,
> *before* passing the resultant proc to #map. And #map has always been
> able to take a proc:
>
>> (1..10).map &lambda {|i| i*2}
> => [2, 4, 6, 8, 10, 12, 14, 16, 18, 20]
>
> So this hasn't really changed anything, it's just added a convenience
> method to symbol. There's actually considerably less magic going on
> than, say, #join's automatically converting everything to strings, and
> the complexity is a result of that lack of magic.

Interesting -- I perceive it as quite magic, maybe because no matter
how long I stare at it, &:m doesn't say "block based on iteration with
method named 'm'" to me.

Mind you, there's *still* room for doing something with the argument
to map :-)


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)