[ruby-core:35422] Re: Why are hash keys sometimes duped?

On 3/1/11 9:25 PM, Yukihiro Matsumoto wrote:
> Hi,
>
> In message "Re: [ruby-core:35409] Re: Why are hash keys sometimes duped?"
>      on Wed, 2 Mar 2011 10:38:01 +0900, Aaron Patterson<[e-mail]>  writes:
>
> |>  Eric, your guess is correct.  It's a compromise between mutable
> |>  strings and rehashing.

Perhaps mutating hash keys should be "behavior is undefined" just like 
deleting keys while iterating is "undefined" (at least that what I read 
somewhere):

hash.each do | k, v |
   hash.delete(k) if v == foo
end

"Undefined" is often "least unexpected", esp. for those who understand 
how classical data structures work.  In this case, it's reasonable to 
expect that the identities (#object_id) of keys are untouched, just like 
other containers, which is why the OP was surprised -- the default #== 
and #hash methods are defined in terms of #object_id.

Rubyists define #== and #hash in other classes to suit their needs.  Is 
there a mechanism such that one can declare which keys are duped and 
which are not?  If #hash and #== are defined recursively, how deep 
should the #dup go?  If it is deep, what about shared/aliased objects?

If a programmer mutates a hash key and breaks hash/equality invariance, 
that programmer can fix his/her code, but everybody must fix programs
that suffer from poor performance or odd behavior when an implementation 
decision becomes standard behavior.

Declaring key mutation as "undefined" is a reasonable design decision -- 
it stops the need to declare additional complex/arbitrary behavior and 
forces those who use a core data structure to understand how it works 
when they misuse it.

Respectfully,
Kurt