From: "David A. Black" <dblack@...>
Date: 2009-08-28T23:11:39+09:00
Subject: Re: #map, #select semantics

Hi --

On Fri, 28 Aug 2009, Rick DeNatale wrote:

> On Fri, Aug 28, 2009 at 6:11 AM, David A. Black<dblack@rubypal.com> wrote:
>
>>> 2. Is part of the contract of #map that you get back a collection of the
>>> same size as the input? If so, what happens if you #map a Set and produce
>>> duplicates? The output will be smaller than the input (similarly for hash
>>> key collisions). Certainly from an FP viewpoint, a map is a one-to-one
>>> transform from input to output values, so it would seem logical to have as
>>> many output values as input values.
>>
>> I think any quasi-mappish operation that departs from real map
>> semantics would have to be a different method. Mapping an enumerable
>> through a function to an array is just too basic and too useful not to
>> be available.
>
>
> I think there are two sides to that.  If you think of the world of
> collections primarily as arrays, then this makes sense.

I wouldn't extrapolate a world-view from it :-) None of this has to
be winner-take-all; there's room for all of these methods to exist. I
just like having a foundational map operation that returns a result
set in an array. I'm not ruling out other kinds of functionality, nor
claiming that non-array collections are actually arrays.

For example:

class Hash
   def map2     # or whatever
     h = {}
     each do |k,v|
       k2, v2 = yield(k,v)
       h[k2] = v2
     end
     h
   end
end

h = {1 => 2, 3 => 4 }

p h.map2 {|k,v| [k*10, v-1] }

   # => {30=>3, 10=>1}

Nothing wrong with having such a method. I just don't think it's a
candidate to replace Hash#map.


David

-- 
David A. Black / Ruby Power and Light, LLC / http://www.rubypal.com
Q: What's the best way to get a really solid knowledge of Ruby?
A: Come to our Ruby training in Edison, New Jersey, September 14-17!
    Instructors: David A. Black and Erik Kastner
    More info and registration: http://rubyurl.com/vmzN