Object.eq is ready for discussion

Brendan Eich brendan at mozilla.com
Sun Sep 5 12:28:23 PDT 2010


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).


> - 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 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?

/be


More information about the es-discuss mailing list