On Aug 24, 2008, at 8:09 PM, Sam Ruby wrote: > If there were an Object.eq method, then 1.1m and 1.10m should be > considered different by such a function. > > I don't believe that decimal, by itself, justifies the addition of an > Object.eq method. Even if we were to go with 1.0m == 1.00m.
Good, that's my position too! Whew. Sorry for the confusion, too much after-hours replying instead of sleeping on my part. > As to what the what the value of 1.0m == 1.00m should be, the amount > of code and the amount of spec writing effort is the same either way. > I can see arguments both ways. But if it were up to me, the > tiebreaker would be what the value of typeof(1.1m) is. If "number", > the scale tips slightly towards the answer being false. If "object", > then then scale is firmly on the side of the answer being true. Ah, typeof. No good can come of making typeof 1.0m == "number", but there is more room for non-singleton equivalence classes in that choice. We have -0 == 0 already. Making cohorts equivalence classes under == seems both more usable and more compatible if the operands have "number" type(of). If they're "object" then we have no precedent: o == p for two object references o and p is an identity test. In spite of this lack of precedent, I believe we are free to make 1.0m == 1.00m if typeof 1.0m == "object". But what should typeof 1.0m evaluate to, anyway? I don't believe "number" is right, since 0.1 == 0.1m won't be true. Is anyone seriously proposing typeof 1.0m == "number"? If Decimal is an object type, then typeof 1.0m == "object" is good for a couple of reasons: * Future-proof in case we do add a primitive decimal type, as ES4 proposed -- a peer of double that shares Number.prototype; typeof on a decimal would return "number". See below for the possibly-bogus flip side. * Analogous to RegExp, which has literal syntax but is an object (RegExp is worse because of mutable state; Decimal presumably would have immutable instances -- please confirm!). Making typeof 1.0m == "object" could be future-hostile if we ever wanted to add a decimal primitive type, though. We're stuck if we treat literals as objects and tell that truth via typeof. We can't make them be "number"s some day if they are objects in a nearer edition, with mutable prototype distinct from Number.prototype, etc. At least not in the ES4 model, which has had some non-trivial thought and RI work put into it. Probably at this point, any future number types will have to be distinct "object" typeof-types, with magic (built-in, hardcoded) or (generic/multimethod) non-magic operator support. That may be ok after all. We never quite got the ES4 model whereby several primtiives (at one point, byte, int, uint, double, and decimal) could all be peer Object subtypes (non-nullable value types, final classes) that shared Number.prototype. We cut byte, int, and uint soon enough, but problems remained. I can't find any changes to 11.4.3 "The typeof Operator" in ES3.1 drafts. Am I right to conclude that typeof 1.0m == "object"? Sorry if I'm beating a dead horse. Just want it to stay dead, if it is dead ;-). > All things considered, I would argue for false. I just wouldn't dig > in my heels while doing so. I was playing down the importance of this design decision to highlight the separable and questionable addition of Object.eq, but I do think it's important to get == right for the case of both operands of Decimal type. I'm still sticking to my 1.0m == 1.00m story, while acknowledging the trade-offs. No free lunch. /be _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
