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