AA key conversion woes

[Jerry]

Sean Kelly <sean at invisibleduck.org> writes:

> On Apr 17, 2012, at 11:41 AM, H. S. Teoh wrote:
>> 
>> 2) Where things get hairy is when non-trivial keys are stored. Take
>> arrays for example. If the user declares int[int[]], then we need an
>> .idup so that we can store the key as immutable(int)[] (or should that
>> be immutable(int[])?). But now if the user passes in an int[] key, we
>> will need to .idup it in order to store it. This is acceptable, but what
>> should .keys return?  If I were the user, I'd expect int[][], but since
>> we can't implicitly convert immutable(int)[] to int[], we need a .dup
>> for each key.  Which introduces unnecessary overhead, since for the most
>> part the user doesn't need to change the keys anyway. But handing back
>> immutable(int)[][] from .keys will break a lot of existing code.
>
> I'm inclined to say that if a reference type is used as a key to an AA, the user either has to promise not to change (assumeUnique) it or explicitly .idup it himself on insertion.

+1.  If AA's insist on immutable object keys, I worry that that will
force more folks to roll their own hashtables when working with large
tables where the cost of duping all those keys actually matters.

Also, I have found it useful on a number of occasions to key a hashtable
with an object where the hash function is only computed on part of the
object and the rest is mutable.

Jerry