[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
not all hashes are created equal...
- To: <xtech>
- Subject: not all hashes are created equal...
- From: Eric Dean Tribble <tribble>
- Date: Sat, 28 Apr 90 00:03:21 PDT
We really made a hash of equality test in MuTable. In thinking about
Ravi's proposal, I ran into some interesting problems:
MuTables all had identical isEqual: tests (based on identity :-), but
many of them had content based hashes. This means that they could get
hashed, change, then hash differently. Yikes!
I implemented contentsHash and contentsEqual: in ScruTable. They are
based on the keys and values of the *current* state. Modularity
demands that these operations ignore implementation differences
between tables. Thus, an Array, an ImmuTableOnMu (on an
IntegerTable), and a HashTable that all map from the same Integers to
the same values had better be contentsEqual:! and have equal
contentsHash! contentsEqual can be optimized by checking the
representation of the other table and doing a faster equality test if
it's possible (WordArray just compares string, for instance). Note
that the MuTable special cases fall back on the general case always.
An ImmuTable is equal to another ImmuTable iff they are contentEqual.
Note that ImmuTables are currently only equal to other ImmuTables. I
don't know what to do yet about ScruTable views onto ImmuTables that
have the same contents....
ScruTables represent a perspective on another table, so they are equal
if their other tables are equal, and they share the same perspective.
(See the code for examples).
I moved some of the old MuTable hash functions into methods named
fastHash in case we need any of them. Please comment on their
utility, as I want to get rid of them eventually. I suspect that we
can reimplement any actual use of them into something better (that
doesn't actually hash).
IsEqual: and hashForEqual are defined as subclassResponsibility in
ScruTable. The only implementations are MuTable (identity based),
ImmuTable (content and immutability based), concrete scruTable
classes (subTable and aspect based), and concrete MuTable classes
(optimizations for special cases).