On Sun, Aug 24, 2008 at 7:01 PM, Brendan Eich <[EMAIL PROTECTED]> wrote:
> You're assuming 1.0m === 1.00m must be true. I'm disputing that (see
> exchange with Sam, who may agree).
Indeed. One of the ES3.1 phone calls characterized the two early positions as
* The typeof school: ES3 currently has the regularity
(typeof x == typeof y && x == y) iff x === y
Let's not break that regularity. It's a good idea, and existing code
may count on it.
* The eq school: ES3 currently has the regularities that
except for NaN, === is an equivalence relation
for all x,y except for -0, x === y implies x is observably
indistinguishable for y
Let's not break those regularities. It's a good idea, and existing
code may count on it.
If === remains as good an indistinguishability test as it is now --
with only the above two exceptions -- then I'd agree we don't need
Object.eq. Libraries could provide it without undue burden. However,
assuming you agree that 1.0m == 1.00m, then you'd break the regularity
in the first bullet. Were that the case, I would soften my normal
avoidance of == to "When you know you've got two numbers (e.g. after
typeof checks) and you want numeric equality, use ==. Otherwise,
always use ===." A problem with this softer stance is it makes it much
harder for JSLint-like tools to warn about uses of == that should be
avoided. Nevertheless, I would be happy with this resolution.
> I'm trying to avoid too much creature feep in any edition ;-). Other
> languages have near-universally-quantified hashcode analogues but solve NaN
> dilemmas by throwing (Python, IIRC).
FWIW, E has exactly two equality operators:
* x == y implies observable equivalence, but operates more like
Henry Baker's EGAL operator than like Lisp's EQ.
NaN == NaN // yields true
-0.0 == 0.0 // yields false
* x <=> y means "According to x, x and y are the same magnitude".
NaN <=> NaN // yields false
-0.0 <=> 0.0 // yields true
> We can enlarge the language to be
> strictly more expressive, or we could enlarge equivalence classes under ===,
> or we could choose to make certain seemingly equal numbers !==. The
> rationale for excluding the last two alternatives when mooting Object.eq is
> not clear.
Re second alternative: don't you mean "shrink equivalence classes",
ideally to singletons, ignoring {-0, 0}?
--
Cheers,
--MarkM
_______________________________________________
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
