From: Gavin Sinclair <gsinclair@...>
Date: 2003-07-21T23:34:39+09:00
Subject: Re: Proposal: Array#to_h, to simplify hash generation

On Monday, July 21, 2003, 8:18:50 PM, dblack wrote:

> Hi --

> On Mon, 21 Jul 2003, Gavin Sinclair wrote:

>> I like "make_hash".  We would get more flexibility if "make_hash" insisted
>> on receiving two values for the block: one for key and one for value.  In
>> one instance recently, I wanted to map the "filename" part of a data
>> object to the object itself.  This, I think, is readable:
>>    map = receipts.make_hash { |r| r.filename, r }
>>
>> Whereas in my pet case of mapping filename to size, we have
>>
>>    map = filenames.make_hash { |fn| fn, File.stat(fn).size }
>>
>> And your example comes out as
>>
>>    (1..10).make_hash { |i| i, f(i) }

> (Wouldn't you have to wrap your two return values in an array to get
> the above to parse?)

I was kinda hoping not, but so be it.  The thin veneer of presenting
tested code vanishes before everyone's eyes.  I was surprised to
discover today that code (1) below works, but not code (2).

  (1) def foo; 2,4; end
  (2) def foo; return 2,4; end

>> I've raised an RCR for this (#148).

> I'm not sure how this differs from (rejected) RCR#12 (except for
> having to return a key as well as a value).

How did O.J. Simpson's second trial differ from his first? ;)

Anyway, I think returning a key as well as a value is a significant
difference:
 - much more flexible (I create all kinds of hashes all the time in
   my code, and could really use that flexibility)
 - less magical, more scrutible: having two values makes it clear what
   is going on, given that we're dealing with a hash.  With the
   single-value to_hash/hashify, I had to keep reminding myself what
   it meant; not so with the new "make_hash".

Gavin