On Aug 24, 2008, at 9:34 AM, Sam Ruby wrote:
What should the result of the following expressions be:
1.5m == 1.5
1.5m === 1.5
typeof(1.5m)
A case could be made that both binary64 and decimal128 are both
numbers, and that a conversion is required.
For ==, yes. For ===, never!
A case could be made that
while they are both numbers, the spec needs to retain the behavior
that users have come to expect that conversions are not performed for
strict equality.
We must not make strict equality intransitive or potentially side-
effecting. Please tell me the case should be made, not just could be
made.
And finally, a case could be made that the result of
typeof(1.5m) should be something different, probably "decimal", and
that decimal128 values are never strictly equal to binary64 values,
even when we are talking about simple integers.
I'm sympathetic to the "decimal128 values are never strictly equal to
binary64 values" part of this case, but that's largely because I am
not an advocate of === over == simply because == is not an
equivalence relation. == is useful, in spite of its dirtiness.
Advocates of === for all use-cases, even those written by casual or
naive JS programmers, are just setting those programmers up for
confusion when === is too strict for the use-case at hand -- and
they're setting up the TC39 committee to add three more equality-like
operators so we catch up to Common Lisp :-(.
The place to hold this DWIM fuzzy line is at ==. Do not degrade ==='s
strictness.
The typeof question should be separated. You could have typeof return
"number" for a double or a decimal, but still keep === strict. I
believe that would be strictly (heh) more likely to break existing
code than changing typeof d to return "object" for Decimal d.
I don't see why we would add a "decimal" result for typeof in the
absence of a primitive decimal type. That too could break code that
tries to handle all cases, where the "object" case would do fine with
a Decimal instance. IIRC no one is proposing primitive decimal for
ES3.1. All we have (please correct me if I'm wrong) is the capital-D
Decimal object wrapper.
Guy Steele, during ES1 standardization, pointed out that some Lisps
have five equality-like operators. This helped us swallow === and !==
(and keep the == operator, which is not an equivalence relation).
Must we go to this well again, and with Object.eq (not an operator),
all just to distinguish the significance carried along for toString
purposes? Would it not be enough to let those who care force a string
comparison?
I think that a "static" Decimal method (decNumber calls this
compareTotal) would suffice. Others believe this needs to be
generalized. I don't feel strongly on this, and am willing to go with
the consensus.
Premature generalization without implementation and user experience
is unwarranted. What would Object.eq(NaN, NaN) do, return true?
Never! Would Object.eq(-0, 0) return false? There's no purpose for
this in the absence of evidence. I agree with you, compareTotal or
something like it (stringization followed by ===) is enough.
/be
_______________________________________________
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
