Hi --

On Wed, 4 Jun 2008, Martin DeMello wrote:

> On Tue, Jun 3, 2008 at 10:50 AM, David A. Black <dblack / rubypal.com> wrote:
>> On Tue, 3 Jun 2008, Gary Wright wrote:
>>>
>>> If Array#map returns an array and Set#map returns a set, then shouldn't
>>> Hash#map return a hash?
>>
>> Possibly it should, but not because of Array#map or Set#map. There's
>> so much nuance to how all these Enumerable classes play out, in terms
>> of their enumerability, that I don't think a universal rule is
>> possible. I'm thinking of things like Range and File, as well as any
>> number of classes that might be written mixing in Enumerable but that
>> would not make sense as return values for a mapping.
>
> Hash#map gets tricky all by itself, too - is it
>
> def map(hash)
>  a = {}
>  hash.each {|k, v|
>    f = yield [k,v]
>
>    # option 1 :
>    a[f[0]] = f[1]
>
>    # option 2 :
>    a[k] = f
>
>    # option 3 :
>    a[k] ||= []; a[k] << f
>
>    # option 4:
>    a[f[0]] ||= []; a[f[0]] << f[1]
>  }
>  return a
> end

I should say that, in spite of my having raised the map/map! question
with respect to Set, I've always been quite happy to have Array serve
as the catch-all container method for most enumerable operations. In
fact my point about Set was (perhaps subtly) different from where the
thread has gone; I was noticing that sets, uniquely (outside of
arrays), have a map! method, and that since Set#map! returns a set,
that got me thinking that perhaps it had a map! method *because* it's
meaningful to talk about a set mapping to a set; and that, in turn,
suggested that maybe plain old map'ping a set should take advantage of
that ability.


David

-- 
Rails training from David A. Black and Ruby Power and Light:
   INTRO TO RAILS         June 9-12            Berlin
   ADVANCING WITH RAILS   June 16-19           Berlin
See http://www.rubypal.com for details and updates!