Re: CVS update: goo/src/goo/cols

[Andrew Sutherland <sombrero@xxxxxxxxxx>]

Perhaps the best thing here would be to maintain a consistent
distinction between == and =, with == remaining address equality and =
indicating semantic equivalency.  We could then construct a new
hash-table sub-class <val-tab> (or some other equally catchy name)
that uses = for equivalency testing.

Then the question is what to do about hashing vis a vis the two
tables.  In Java (as you know), Object implements int hashCode(),
which defaults to hashing on the address, which of course jives with
equals() which defaults to an address-equivalency test.  Class
designers may then override these with the constraint that a.equals(b)
=> (a.hashCode() == b.hashCode()).  Goo needs an equivalent to
hashCode() for user purposes, and it seems like using id-hash which is
currently used by the <tab> implementation would be a bad thing.

>From an implementation perspective, I can see why having a hash table
that works solely on addresses is beneficial; it allows you to
basically tack meta-data onto specific instances of objects (with the
caveat that tagged types such as integers can only have one-instance
in the table).  If id-hash doubled as hashCode(), the result in <tab>
would be inefficient collisions in hashSpace.

So here's my proposal:

- Cull the methods in the id-hash generic to those directly required
  to hash on unique object instances.  (aka, revert my patch)

- Create a generic hash(o|<any>) or hashcode that is designed for
  users to implement for their classes as well.  Provide defaults for
  goo base-classes that maintains consistency for containers, strings,
  etc.

- Create a class <val-tab> that uses hash as its hash function and =
  as its equivalency function. (There's no reason for users to have to
  create their own table subclasses.)

- Put it on the to-do list to revert the == behavior for <col> and
  <seq> to be address equivalency again.  (Perhaps go so far as to
  make == a function (df) so that people can't do bad/stupid things.)
  I say to-do, because I'm sure there's a hack reason that == behaves
  like = on those classes that will break goo if changed.

- Move <str-tab> like you suggested, as its need will be obviated by
  <val-tab> and the fact that 'hash' will be implemented on strings.

Andrew