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

[Jonathan Bachrach <jrb@xxxxxxxxxx>]

andrew,

i agree with your proposal.  let's do it.  i refer people to the dylan
reference manual for more material on the subject:

  http://www.gwydiondylan.org/drm/drm_67.htm#HEADING67-0

jonathan

Andrew Sutherland <sombrero@ai.mit.edu> writes:

> 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