Es-discuss - several decimal discussions

Brendan Eich brendan at
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  
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.


More information about the Es-discuss mailing list