From: dblack@...
Date: 2006-12-14T10:07:41+09:00
Subject: Re: map taking an argument (was: Re: join_with)

Hi --

On Thu, 14 Dec 2006, ara.t.howard@noaa.gov wrote:

> On Thu, 14 Dec 2006 dblack@wobblini.net wrote:
>
>> Hi --
>> 
>> On Thu, 14 Dec 2006, Christian Neukirchen wrote:
>> 
>>> "Martin DeMello" <martindemello@gmail.com> writes:
>>> 
>>>>> (1..10).map &lambda {|i| i*2}
>>>> => [2, 4, 6, 8, 10, 12, 14, 16, 18, 20]
>>> 
>>> David, do you want to allow  (1..10).map(:*, 2)  ?
>> 
>> I don't particularly want to allow map(:anything) :-)  I was just
>> somewhat surprised to see the idea return in a slightly new form,
>> since Matz had rejected it a while ago.
>> 
>> If I were designing map(:name), I don't think I'd want it to take
>> arguments.  But I have no technical grounds for saying so, only
>> aesthetic ones.
>
> you confound me david!  ;-)
>
> if you like 'e.map :m' how can you __not__ like
>
>  harp:~ > cat a.rb
>  class Array
>    def map *a, &b
>      m, *a = *a
>      super &(b || lambda{|o| o.send m, *a})
>    end
>  end
>
>  prefixes = %w( foo-bar bar-foo ).map :[], /^\w+/
>  p prefixes
>
>
>  harp:~ > ruby a.rb
>  ["foo", "bar"]
>
> ?

I didn't say I liked e.map(:m); I said I wondered why it was rejected
and now the same functionality has returned in a noisier form :-)

But the broader answer is: because I don't think about Ruby design
questions as a matter of one thing leading inexorably to another.
Liking e.map(:m) would not imply liking anything else.

I suppose I've answered my own question, in a sense: Matz's dislike of
map(:m) does not imply disliking anything else, including map &:m.
That principle is so important.  I'm even willing to pay the price of
&:m to see it upheld :-)


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)