Separating a Hash type from Object

Brendan Eich brendan at mozilla.org
Wed May 30 17:52:54 PDT 2007


On May 30, 2007, at 5:20 PM, Jason Orendorff wrote:

> On 5/29/07, Brendan Eich <brendan at mozilla.org> wrote:
>> * key/value type parameterization, hashcode callback function
>> parameterization
>> * defaults to intrinsic::=== and intrinsic::hashcode for identity and
>> hashing
>
> OK, it strikes me as a little weird, now, to use intrinsic::=== and
> intrinsic::hashcode() here.

You are racing ahead of us here :-). Lars raised this issue in the  
wiki, we haven't resolved it.

> Java, Python, and Ruby let individual *classes* (rather than  
> individual
> hash tables) override hash() and equals().  I think this supports
> generic code better.
>
>   function uniq(values) {
>       var d : Dict = {};  // nothing special here
>       for each (var v in values)
>           d.put(v, true);
>       return d.keys();
>   }
>
> Also, if I were distributing a JavaScript library, I would be happier
> saying "you can use FooBar objects as hash table keys" than
> "if you want to use a FooBar as a hash table key, you need to pass
> these two magic functions to the Dictionary constructor when you
> create the Dictionary: new Dictionary(FooBar.eq, FooBar.hash)".

There aren't two magic funargs, because === is part of the Key type  
parameter, if you want it to be, via the

http://developer.mozilla.org/es4/proposals/operators.html

proposal, as a static operator function. But there is no static or  
member/prototype hashcode method to match ===. Instead, in the latest  
Dict write-up, there is a hashfn constructor funarg, defaulting to  
the intrinsic::hashcode global function, or another like it you can  
supply as the hashfn funarg's non-default value when constructing a  
Dict.

The http://developer.mozilla.org/es4/proposals/hashcodes.html  
proposal was all about minimalism in ES4 to support a self-hosted  
collections ecosystem, but built with objects as hash table chain  
items, arrays as bucket vectors, etc.

Perhaps that is useful still -- it allows hashing null and undefined,  
which are not objects so can't be denoted by a variable x and hashed  
via a method call x.hashcode() -- but it seems an  
Object.prototype.hashcode or (to match the operators proposal) a  
static hashcode method would be better for Dict and similar  
collection types.

So yeah, this sucks. We will fix it.

/be



More information about the Es4-discuss mailing list