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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
