Separating a Hash type from Object

[Brendan Eich]

On May 30, 2007, at 5:50 PM, Graydon Hoare wrote:

> Jason Orendorff wrote:
>
>> OK, it strikes me as a little weird, now, to use intrinsic::=== and
>> intrinsic::hashcode() here.
>>
>> Java, Python, and Ruby let individual *classes* (rather than  
>> individual
>> hash tables) override hash() and equals().  I think this supports
>> generic code better.
>
> Not all objects in ES4 are of an interesting class, or implement an
> interesting interface. Think structural types: the nearest class of  
> the
> type "{a:int}" is "Object".
>
> Still, it's pretty easy to have both:
>
> function defaultHash.<K>(k:K) : uint {
>    switch type (k) {
>      case (h:Hashable) {
>        return h.hash();
>      }
>      default {
>        intrinsic::hashcode(k);

Don't you (I) wish it were an expression language, like ML ;-).

>      }
>    }
> }
>
> function defaultEq.<K>(a:K, b:K) : bool {
>    switch type (k) {
>      case (h:Equality) {
>        return a.equals(b);
>      }
>      default {
>        return a === b;
>      }
>    }
> }
>
> class Dict.<K,V> {
>    function Dict(hash=defaultHash.<K>, eq=defaultEq.<K>)
>    {
>     ...
>    }
> ...
> }

We could provide all this in the standard Dict.es, for sure. Good use  
of type, function, and optional parameters. But then we'd have to  
define Hashable and Equality too. Could be done, but these imply  
further design decisions (perhaps there should be only one type with  
hash and equals methods, instead of two types).

/be