From: amrit@xvt.com (Consultant)
Subject: Re: Invertible id(), or maybe hash the world, or ?
To: wiml@netcom.com (William Lewis)
Date: Tue, 5 Apr 1994 15:25:49 -0600 (MDT)
>
> It seems to me that it would be a simpler solution for mapping objects to
> simply use the 'id' of an object as its hash if it doesn't provide a hash
> method. The 'id' has most of the desirable attributes of a hash: it's
> unique, it doesn't change over the lifetime of the object, and it's small
> and easily computed. The one thing it's missing is that it doesn't work
> for some types (eg strings) for which two different objects can be equal.
> But for those objects, we can just have a real hash method.
>
The problem with hashing id's is that the user has to look up an object with
the same >>identity<<. Looking up an object with the same value will not
work:
>>> dict = {['a', 'c']: 3}
>>> print dict[['a', 'c']]
KeyError exception raised here!
The problem is that ['a', 'c'] is a different list identity-wise than the
one in the table. Icon hashes by ID's for lists and records, but the behavior
is very non-intuitive, very confusing and error prone, and is not very useful;
most of the time, you don't know or care if the identities are equal, you are
much more concerned about the values.
(Of course you suggest hashing by value for immutalbe types, but my point is
mainly that I think it's better never to hash by id. I never did like or see
much use to Icon's hash by ID semantics.)
The reason why lists, etc. cannot be hashed is because they are mutable objects,
and changing an object that is a key in a dictionary could ruin the integrity
of the data structure.
------- End of Forwarded Message