Object.eq is ready for discussion

Maciej Stachowiak mjs at apple.com
Sun Sep 5 17:31:23 PDT 2010


On Sep 5, 2010, at 12:28 PM, Brendan Eich wrote:

> On Sep 5, 2010, at 8:28 AM, Maciej Stachowiak wrote:
> 
>> Other possibilities:
>> 
>> - Make Object.hashcode pair with === or == instead of Object.eq: formally impossible, because neither is actually an equivalence relation. Less formally, possible at the cost of making it impossible to use NaN as a hash key, or distinguish 0 from -0 as hash keys.
> 
> === is an ER ignoring NaN (0 and -0 are in the same equivalence class, but whether this is a bug or a feature depends on imponderables; arguably -0 is a bug outside of numerical applications).

That is what I meant by their failure to be an equivalence relation. If you ignore that issue, then you'll be able to put an arbitrary number of different 'NaN'-keyed values in a hashtable based on hashcode, but will never be able to retrieve or remove any of them. Possibly obscure, but seems like a bad consequence if it does happen.

> 
>> - Make Object.hashcode correspond to an equivalence relation that is described but not provided as a predefined function - now actually using hashcode becomes needlessly complicated and error prone.
> 
> This was the consensus (not a strong one) last time we discussed.

It seems like this would significantly increase the odds of data structures built using Object.hashcode and ===, which would result in brokenness. You could get separate entries for '0' and '-0' (since they would hash differently) but later rehashing could cause lookup to find the wrong one. I think the responsible thing to do is to actually expose the equivalence relation that matches hashcode, instead of hoping that everyone bothers to handcode it.

> 
> 
>> It might even be desirable to name Object.hashcode something that makes the relationship to eq clear - Object.eqHash? On the other hand, it seems somewhat unlikely that other hash/equivalence pairs will be introduced to the standard, so maybe it doesn't matter.
> 
> The "eq" name is freakishly short, which might up the odds of it not colliding with existing user-level extensions to Object (egal might work as well in that regard), but we already heard from people objecting to Object.keys vs. Object.getOwnPropertyNames.
> 
> The strawman has a note where I suggested matching "hashcode" with "identity" as the method name. If nothing else, the name length and lack of hackerly abbreviation recommend it. Comments?

I would expect a function named "identity" to be a function of one argument that returns it unmodified, rather than a two-argument predicate that implements an equivalence relation. "eq" seems like an ok name. "egal" will probably seem more mysterious than "eq".

Regards,
Maciej



More information about the es-discuss mailing list