Brendan Eich wrote: > 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.
If we go with "object", a Decimal.parse methods won't be strictly (heh-backatcha) necessary, a Decimal constructor would do. In fact, decimal could also be called as a function. I like it when things become simpler. My only remaining comment is that might tip the scales as to whether or not 1.10m === 1.1m. They certainly are not the same object. But we previously agreed that this one could go either way. > 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 - Sam Ruby _______________________________________________ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
