Issue #7341 has been updated by bitsweat (Jeremy Kemper).


Thanks for posting, Nathan. See https://gist.github.com/4035286 for the full pitch and a demonstration implementation.

In short: associating a collection of keys with calculated values should be easy to do and the code should reflect the programmer's intent. But it's hard for a programmer to discover which API is appropriate to achieve this. Hash[] and each_with_object({}) seem unrelated. And using these API requires boilerplate code that obscures the programmer's intent.


# Must write code to build a Hash[] argument in the format it expects: 
# an array of [key, value] pairs. The intent is hidden by unrelated code 
# needed to operate the Hash[] method.
Hash[*collection.map { |elem| [elem, calculate(elem)] }] 

# This is better. Much less boilerplate code. But the programmer is 
# reimplementing association every time: providing a hash and setting the 
# value for each key in the collection. This is what an *implementation* 
# of association looks like. It shouldn't be repeated in our code.
collection.each_with_object({}) { |elem, hash| hash[elem] = calculate(elem) }

# Most Rubyists just use this instead. It uses simple, easy-to-discover API.
# But it suffers the same issues: it's an *implementation* of association
# that's now repeated in our code, blurring its intent. And it forces us to
# disrupt chains of enumerable methods and write boilerplate code.
hash = {}
collection.each { |element| hash[element] = calculate(element) }

# Now the code is stating precisely what the programmer wants to achieve.
# Associate is easy to find in docs and uses a verb that "rings a bell" to
# programmers who need to associate keys with yielded values.
collection.associate { |element| calculate element }


Marc-André Lafortune proposed a similar Enumerable#associate in #4151. The basic behavior is the same, so I consider that a point in favor of this method name. It associates values with the enumerated keys. He introduces additional collision handling that I consider out of scope. For more complex scenarios, using more verbose, powerful API like #inject, #each_with_object, or #map + #associate feels appropriate.
----------------------------------------
Feature #7341: Enumerable#associate
https://bugs.ruby-lang.org/issues/7341#change-32864

Author: nathan.f77 (Nathan Broadbent)
Status: Open
Priority: Low
Assignee: 
Category: lib
Target version: next minor


Jeremy Kemper proposed Enumerable#associate during the discussion in #7297, with the following details:

-------------------

Some background:

#4151 proposes an Enumerable#categorize API, but it's complex and hard to understand its behavior at a glance.
#7292 proposes an Enumerable#to_h == Hash[...] API, but I don't think of association/pairing as explicit coercion, so #to_h feels misfit.

Associate is a simple verb with unsurprising results. It doesn't introduce ambiguous "map" naming. You associate an enumerable of keys with yielded values.

Some before/after examples:

Before: Hash[ filenames.map { |filename| [ filename, download_url(filename) ]}]
After:  filenames.associate { |filename| download_url filename }
# => {"foo.jpg"=>"http://...", ...}

Before: alphabet.each_with_index.each_with_object({}) { |(letter, index), hash| hash[letter] = index }
After:  alphabet.each_with_index.associate
# => {"a"=>0, "b"=>1, "c"=>2, "d"=>3, "e"=>4, "f"=>5, ...}

Before: keys.each_with_object({}) { |k, hash| hash[k] = self[k] }  # a simple Hash#slice
After:  keys.associate { |key| self[key] }


-------------------

It's worth noting that this would compliment ActiveSupport's Enumerable#index_by method: http://api.rubyonrails.org/classes/Enumerable.html#method-i-index_by
#index_by produces '{<block result> => el, ...}', while #associate would produce '{el => <block result>, ...}'.

For cases where you need to control both keys and values, you could use '[1,2,3].map{|i| [i, i * 2] }.associate', or continue to use 'each_with_object({})'.



-- 
http://bugs.ruby-lang.org/