[ruby-core:19397] [Feature #666] Enumerable::to_hash

[ruby-core:19397] [Feature #666] Enumerable::to_hash

[Marc-Andre Lafortune]

Feature #666: Enumerable::to_hash
http://redmine.ruby-lang.org/issues/show/666

Author: Marc-Andre Lafortune
Status: Open, Priority: Low

There are many ways to obtain an array from enumerables (to_a, map, ...).
There is no natural way to obtain a hash from an enumerable (except for Hash[some_array]).
There is a Hash::to_a but no Array::to_hash.
Here is what I would like:

[[:hello, "world"], [:choice, [:red_pill, :blue_pill]]].to_hash ==> {:hello=>"world", :choice=>[:red_pill, :blue_pill]}
(1..3).to_hash{|n| [n, n**2]} ==> {1 => 1, 2 ==> 4, 3 ==> 9}

I propose to add the following Enumerable::to_hash :

module Enumerable
  def to_hash
    result = {}
    self.each do |key, value|
      key, value = yield(key, value) if block_given?
      result[key] = value
    end
    result
  end
end

Since Hash::to_a returns an array of key-value pairs, I fell it's natural that a block to construct a Hash should return key-value pairs. 
This definition has nice symmetric properties: for any Hash h, the following all return a copy of h.
h.to_a.to_hash
h.to_hash{|p| p}
h.to_hash{|k,v| [k,v]}
h.keys.zip(h.values).to_hash

Thank you for your attention,

Marc-Andre Lafortune


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

[ruby-core:23227] [Feature #666] Enumerable::to_hash

[Marc-Andre Lafortune]

Issue #666 has been updated by Marc-Andre Lafortune.


Anyone eagerly waiting for this feature will be interested to read http://redmine.ruby-lang.org/issues/show/1385
----------------------------------------
http://redmine.ruby-lang.org/issues/show/666

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

[ruby-core:23249] [Feature #666](Rejected) Enumerable::to_hash

[Yukihiro Matsumoto]

Issue #666 has been updated by Yukihiro Matsumoto.

Status changed from Open to Rejected

Enumerable in general does not correspond with mappings, so that I feel Enumerable#to_hash is improper.

----------------------------------------
http://redmine.ruby-lang.org/issues/show/666

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

[ruby-core:23253] Re: [Feature #666](Rejected) Enumerable::to_hash

[trans]

On Apr 18, 8:07 pm, Yukihiro Matsumoto <redm...@ruby-lang.org> wrote:
> Issue #666 has been updated by Yukihiro Matsumoto.
>
> Status changed from Open to Rejected
>
> Enumerable in general does not correspond with mappings, so that I feel Enumerable#to_hash is improper.

I don't see why a corresponance in needed. It's simply a
transformation. I think the real problem lies in the name of the
method proposed. Rather than #to_hash, for instance, in Facets this
method is called #graph or #mash (for "map hash"). Maybe there is a
better name to be had, but it certainly is a useful method to have at
times.

T.

[ruby-core:23259] Re: [Feature #666](Rejected) Enumerable::to_hash

[Yukihiro Matsumoto]

Hi,

In message "Re: [ruby-core:23253] Re: [Feature #666](Rejected) Enumerable::to_hash"
    on Sun, 19 Apr 2009 08:52:54 +0900, trans <transfire@gmail.com> writes:

|I don't see why a corresponance in needed. It's simply a
|transformation.

#to_hash (or whatever name of the method) can only transform
enumerable in certain format, e.g. enumerable of two-elements arrays.
I think this is too much assumption for a method of Enumerable.

OK, I admit we already have some methods with presumption, e.g.
#sort, #min and #max to assume elements to be comparable, but their
usefulness is proven in the history of the language.  Meanwhile, how
often do we need #to_hash?  I haven't, at least.

|I think the real problem lies in the name of the
|method proposed. Rather than #to_hash, for instance, in Facets this
|method is called #graph or #mash (for "map hash"). Maybe there is a
|better name to be had, but it certainly is a useful method to have at
|times.

Any method can be useful for certain situation.  The point is how
often and in what situation it is useful.  I don't see that much
usefulness to make it built in.

							matz.

[ruby-core:23260] Re: [Feature #666](Rejected) Enumerable::to_hash

[Marc-Andre Lafortune]

[-- Attachment #1: Type: text/plain, Size: 2479 bytes --]

Thank you for this explanation. If I understand correctly, you want methods
of Enumerable to remain as generic as possible and not assume anything of
the elements (besides being comparable in some instances). I find this very
reasonable indeed.

Would Array#to_hash be more appropriate, then? Array has methods that assume
some structure on elements of arrays. In particular, #assoc and #rassoc make
the exact same kind of assumptions that #to_hash would make, and #transpose
too.

As for the name, I believe that either #to_hash or #to_h would be the most
appropriate names, and the choice between one or the other depending on if a
translation should occur automatically or not when calling Hash#replace and
Hash::[]. (I think these are the only two?)

If needed, I would be glad to reword this feature request for Array; it
would be even simpler since no block would be needed and the behaviour the
same as Hash::[]. I'm assuming that Hash::[] with an array of arrays is an
official feature even though it's not yet documented (as per #1385), right?

Thank you for your consideration,

Marc-André

On Sun, Apr 19, 2009 at 11:43 PM, Yukihiro Matsumoto <matz@ruby-lang.org>wrote:

> Hi,
>
> In message "Re: [ruby-core:23253] Re: [Feature #666](Rejected)
> Enumerable::to_hash"
>     on Sun, 19 Apr 2009 08:52:54 +0900, trans <transfire@gmail.com>
> writes:
>
> |I don't see why a corresponance in needed. It's simply a
> |transformation.
>
> #to_hash (or whatever name of the method) can only transform
> enumerable in certain format, e.g. enumerable of two-elements arrays.
> I think this is too much assumption for a method of Enumerable.
>
> OK, I admit we already have some methods with presumption, e.g.
> #sort, #min and #max to assume elements to be comparable, but their
> usefulness is proven in the history of the language.  Meanwhile, how
> often do we need #to_hash?  I haven't, at least.
>
> |I think the real problem lies in the name of the
> |method proposed. Rather than #to_hash, for instance, in Facets this
> |method is called #graph or #mash (for "map hash"). Maybe there is a
> |better name to be had, but it certainly is a useful method to have at
> |times.
>
> Any method can be useful for certain situation.  The point is how
> often and in what situation it is useful.  I don't see that much
> usefulness to make it built in.
>
>                                                        matz.
>
>

[-- Attachment #2: Type: text/html, Size: 2979 bytes --]

[ruby-core:23264] Re: [Feature #666](Rejected) Enumerable::to_hash

[Joshua Ballanco]

Hi Matz,

In the past, one of the suggestions for a #to_hash method has been to  
do something similar to #map. That is, to_hash would take a block and  
construct a hash using the elements of the Enumerable as the keys and  
the return value of the block as the values. This solves a slightly  
different problem then originally posed, but I think it would be a  
very useful function (even if it is little more than syntactic sugar  
for inject). In other words:

 > integers = [1, 2, 3, 4, 5, 6]
 > squares = integers.to_hash {|i| i**2}
 > p squares
{1=>1, 2=>4, 3=>9, 4=>16, 5=>25, 6=>36}

Which would be similar to:

 > integers = [1, 2, 3, 4, 5, 6]
 > squares = integers.inject({}) { |a, n| a[n] = n**2; a }

...but I feel the first way is much more straight forward. In addition  
to being prettier, I think a #to_hash like that would be open to more  
optimization than #inject. That is, #inject much pass the accumulator  
to each element in the Enumerable in turn, but #to_hash could  
preallocate the hash keys and evaluate the value blocks in parallel.

Just an idea

- Josh

On Apr 19, 2009, at 11:43 PM, Yukihiro Matsumoto wrote:

> Hi,
>
> In message "Re: [ruby-core:23253] Re: [Feature #666](Rejected)  
> Enumerable::to_hash"
>    on Sun, 19 Apr 2009 08:52:54 +0900, trans <transfire@gmail.com>  
> writes:
>
> |I don't see why a corresponance in needed. It's simply a
> |transformation.
>
> #to_hash (or whatever name of the method) can only transform
> enumerable in certain format, e.g. enumerable of two-elements arrays.
> I think this is too much assumption for a method of Enumerable.
>
> OK, I admit we already have some methods with presumption, e.g.
> #sort, #min and #max to assume elements to be comparable, but their
> usefulness is proven in the history of the language.  Meanwhile, how
> often do we need #to_hash?  I haven't, at least.
>
> |I think the real problem lies in the name of the
> |method proposed. Rather than #to_hash, for instance, in Facets this
> |method is called #graph or #mash (for "map hash"). Maybe there is a
> |better name to be had, but it certainly is a useful method to have at
> |times.
>
> Any method can be useful for certain situation.  The point is how
> often and in what situation it is useful.  I don't see that much
> usefulness to make it built in.
>
> 							matz.
>

[ruby-core:23265] Re: [Feature #666](Rejected) Enumerable::to_hash

[Yukihiro Matsumoto]

Hi,

In message "Re: [ruby-core:23260] Re: [Feature #666](Rejected) 	Enumerable::to_hash"
    on Mon, 20 Apr 2009 13:46:37 +0900, Marc-Andre Lafortune <ruby-core-mailing-list@marc-andre.ca> writes:

|Would Array#to_hash be more appropriate, then? Array has methods that assume
|some structure on elements of arrays. In particular, #assoc and #rassoc make
|the exact same kind of assumptions that #to_hash would make, and #transpose
|too.

For that reason, a method for assoc_to_hash operation might be more
appropriate.  But I still have doubt.

|As for the name, I believe that either #to_hash or #to_h would be the most
|appropriate names, and the choice between one or the other depending on if a
|translation should occur automatically or not when calling Hash#replace and
|Hash::[]. (I think these are the only two?)

First, I personally believe either #to_hash or #to_h would NOT be the
appropriate names.  #to_xxx names are used for implicit conversion
(e.g. to_str, to_int), whereas to_hash is for explicit conversion, as
far as I understand.  Besides that, #to_h is too vague (yeah, same for
#to_s and #to_i etc. but these have long history and tradition).
Probably we need a new name for a new method, even if we come to
consensus to make it built in.


							matz.

[ruby-core:23273] Re: [Feature #666](Rejected) Enumerable::to_hash

[Kurt Stephens]

Perhaps #to_hash should never take arguments so receivers have an
opportunity to return a cached frozen Hash without too much difficulty.

To that end, it would be great if Symbol#to_s always returned a cached
frozen String, but that would probably break too much existing code.  :)

Yukihiro Matsumoto wrote:
> Hi,
>
> In message "Re: [ruby-core:23260] Re: [Feature #666](Rejected) 	Enumerable::to_hash"
>     on Mon, 20 Apr 2009 13:46:37 +0900, Marc-Andre Lafortune <ruby-core-mailing-list@marc-andre.ca> writes:
>
> |Would Array#to_hash be more appropriate, then? Array has methods that assume
> |some structure on elements of arrays. In particular, #assoc and #rassoc make
> |the exact same kind of assumptions that #to_hash would make, and #transpose
> |too.
>
> For that reason, a method for assoc_to_hash operation might be more
> appropriate.  But I still have doubt.
>
> |As for the name, I believe that either #to_hash or #to_h would be the most
> |appropriate names, and the choice between one or the other depending on if a
> |translation should occur automatically or not when calling Hash#replace and
> |Hash::[]. (I think these are the only two?)
>
> First, I personally believe either #to_hash or #to_h would NOT be the
> appropriate names.  #to_xxx names are used for implicit conversion
> (e.g. to_str, to_int), whereas to_hash is for explicit conversion, as
> far as I understand.  Besides that, #to_h is too vague (yeah, same for
> #to_s and #to_i etc. but these have long history and tradition).
> Probably we need a new name for a new method, even if we come to
> consensus to make it built in.
>
>
> 							matz.
>
>   

[ruby-core:23277] Re: [Feature #666](Rejected) Enumerable::to_hash

[Marc-Andre Lafortune]

Thank you for your response

On Mon, Apr 20, 2009 at 2:13 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
> For that reason, a method for assoc_to_hash operation might be more
> appropriate.  But I still have doubt.

Let me attempt to dissolve (some of) your doubts. I checked rapidly
rails' code. I found over 40 "inject({})" and looking at them reveals
that most could be improved using #to_hash.

For example, the first ones I found could be rewritten as follows:

# part_container.rb
attrs = attrs.inject({}) { |h,s| k,v = s.split(/=/, 2); h[k] = v; h }
# ==>
attrs = attrs.map{ |s| s.split(/=/, 2) }.to_hash


# route_set.rb (meta programming)
args = args.zip(#{route.segment_keys.inspect}).inject({}) do |h, (v, k)|
  h[k] = v
  h
end
# ==>
args = args.zip(#{route.segment_keys.inspect}).to_hash


# route_set.rb
recall.inject({}) do |expiry, (key, recalled_value)|
  expiry[key] = (options.key?(key) && options[key].to_param !=
recalled_value.to_param)
  expiry
end
# ==>
recall.to_hash do |key, recalled_value|
  [key, (options.key?(key) && options[key].to_param != recalled_value.to_param)]
end

# etc...

These are easy to find but are not the only instances that could be
improved, of course. Here's another example I found:

# routes.rb
@parameter_shell ||= returning({}) do |shell|
  requirements.each do |key, requirement|
    shell[key] = requirement unless requirement.is_a? Regexp
  end
end
# ==>
@parameter_shell ||= requirements.reject{|key, requirement|
requirement.is_a? Regexp}.to_hash

I believe the latter form is not only more concise but much more expressive.

My final comment would be that although 40 inject({}), a couple of
returning({}) and other places I don't know of in the whole of rails'
code is not that much. Just for comparision's sake, there are only 2
uses of #assoc, 0 of #rassoc, 1 of #partition, 3 of #grep, etc... So I
believe that #to_hash would be reasonably useful.

Thank you,

Marc-André

[ruby-core:23295] Re: [Feature #666](Rejected) Enumerable::to_hash

[Michael Fellinger]

On Wed, 22 Apr 2009 05:45:06 +0900
Marc-Andre Lafortune <ruby-core-mailing-list@marc-andre.ca> wrote:

> I believe the latter form is not only more concise but much more
> expressive.
> 
> My final comment would be that although 40 inject({}), a couple of
> returning({}) and other places I don't know of in the whole of rails'
> code is not that much. Just for comparision's sake, there are only 2
> uses of #assoc, 0 of #rassoc, 1 of #partition, 3 of #grep, etc... So I
> believe that #to_hash would be reasonably useful.

Doesn't the new behaviour of Hash::[] solve these cases just as well?

-- 
^ manveru

[ruby-core:23298] Re: [Feature #666](Rejected) Enumerable::to_hash

[Marc-Andre Lafortune]

On Thu, Apr 23, 2009 at 9:55 AM, Michael Fellinger
<m.fellinger@gmail.com> wrote:

> Doesn't the new behaviour of Hash::[] solve these cases just as well?

Yes indeed it does, but

1) The new form of Hash[] has yet to be confirmed by Matz (see
http://redmine.ruby-lang.org/issues/show/1385 ).

2) It's not as natural as #to_hash. Don't we usually use instance
methods to convert between types? If you look at conversion between
basic types, you can convert:
Numeric <=> String <=> Symbol
Hash => Array
All these using instance methods. The only arrow missing is from Array
back to Hash!


I'm not sure I understand the rationale behind Hash[] or Array[].
Their existence doesn't hurt but I don't think they are getting much
use. In rails' code, there are no use of Array[] and two of Hash[],
both of which building an array of key-value pairs, then flattening it
before calling Hash[]. They would thus also benefit from the new form
of Hash[] (if it is confirmed as a feature) or, more nicely and
naturally, of a new Array#to_hash. My opinion is that it's much better
to be consistent and have an instance method of Array to get a hash
than to promote the use of an unfamiliar and unpopular use of a class
method.

Thanks

[ruby-core:23433] Re: [Feature #666](Rejected) Enumerable::to_hash

[Yukihiro Matsumoto]

Hi,

In message "Re: [ruby-core:23298] Re: [Feature #666](Rejected) 	Enumerable::to_hash"
    on Fri, 24 Apr 2009 00:08:53 +0900, Marc-Andre Lafortune <ruby-core-mailing-list@marc-andre.ca> writes:
|
|On Thu, Apr 23, 2009 at 9:55 AM, Michael Fellinger
|<m.fellinger@gmail.com> wrote:
|
|> Doesn't the new behaviour of Hash::[] solve these cases just as well?
|
|Yes indeed it does, but
|
|1) The new form of Hash[] has yet to be confirmed by Matz (see
|http://redmine.ruby-lang.org/issues/show/1385 ).

Didn't I?  I confirm.

|2) It's not as natural as #to_hash. Don't we usually use instance
|methods to convert between types? If you look at conversion between
|basic types, you can convert:
|Numeric <=> String <=> Symbol
|Hash => Array
|All these using instance methods. The only arrow missing is from Array
|back to Hash!

Even though a hash can be represented by an array, there's not always
natural map from Array to Hash.  I am not sure how much to_hash is
useful, when we cannot define what [1,2,3].to_hash should return.

							matz.

[ruby-core:23439] Re: [Feature #666](Rejected) Enumerable::to_hash

[Marc-Andre Lafortune]

Hi!

On Tue, May 12, 2009 at 2:43 AM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
> Didn't I?  I confirm.

Great, thanks! I've added the new syntax to RubySpecs.

> Even though a hash can be represented by an array, there's not always
> natural map from Array to Hash.  I am not sure how much to_hash is
> useful, when we cannot define what [1,2,3].to_hash should return.

I feel it is similar to:

"foo".to_i  # ==> 0
Hash[ [1,2,3] ]  # ==> {}
So we could have:
[1,2,3].to_hash # ==> {}

Thanks again for the confirmation, I can use that until one day maybe
the "object form" becomes available.