On Friday, 16 Mar 2012 at  1:13 PM, Yukihiro Matsumoto wrote:
> Hi,
> 
> In message "Re: [ruby-core:43310] [ruby-trunk - Feature #5008] Equal
> rights for Hash (like Array, String, Integer, Float)" on Fri, 16 Mar
> 2012 02:58:04 +0900, Suraj Kurapati <sunaku / gmail.com> writes:
> 
> |Request #3131 was fulfilled, so here is the updated feature matrix:
> | 
> | |           |   Kernel    |  Implicit  |  Explicit  |  NilClass   |
> | |   Class   |   method    | conversion | conversion | conversion  |
> | | --------- | ----------- | ---------- | ---------- | ----------- |
> | |  String   |  String()   |   to_str   |    to_s    |  nil.to_s   |
> | |  Integer  |  Integer()  |   to_int   |    to_i    |  nil.to_i   |
> | |   Float   |   Float()   |  MISSING   |    to_f    |  nil.to_f   |
> | |   Array   |   Array()   |   to_ary   |    to_a    |  nil.to_a   |
> | |   Hash    |    Hash()   |  to_hash   |  MISSING   |   MISSING   |
> 
> This table means nothing.  Are you going to expand the table for every
> class Ruby would provide, e.g. Complex, Rational, Range, etc?

No, this proposal is just for Hash because it is one of the two most
commonly used data structures in Ruby/Perl/JSON/YAML: Array and Hash.

Amdahl's Law says "make the common case fast"; in this case, since Hash
is so frequently used, we would all benefit by making it s/fast/easy/.

That is why I wrote that feature comparison matrix: to highlight the
second-class treatment of Hash (in comparison to Array) in Ruby's API.

> Repeating myself, unlike other classes in the table, Hash does not
> have "natural" conversion from set of values, so that I don't think
> it's worth provide to_h method.
> 
> In [ruby-core:43321], Marc-Andre claims "any choice here is better
> than no choice".  But I disagree.  For "any choice", we already have
> Hash[value].

Fair enough.  I agree with Marc-Andre, but you're the boss.  I will just
have to live a gem that provides #to_h.  Thanks for your consideration.