Es-discuss - several decimal discussions
brendan at mozilla.org
Sun Aug 24 22:44:20 PDT 2008
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
* 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.
More information about the Es-discuss