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.
>
>