Es-discuss - several decimal discussions

Sam Ruby rubys at intertwingly.net
Mon Aug 25 04:29:30 PDT 2008


On Mon, Aug 25, 2008 at 1:44 AM, Brendan Eich <brendan at mozilla.org> wrote:
> 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".

Note: that was a typo on my part.  We agree here.

> 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"?

My working assumption coming out of the SF/Adobe meeting was that in
ES4 there would be both a primitive decimal, which could be wrappered
by the Number class, which is much in line with what you mentioned
below.  Based on your recent input, I now question the need to provide
a decimal primitive ever.

Note: here I'm talking about the conceptual model that the language
exposes.  Doubles are GC'ed in SpiderMonkey, as would be decimals.

> 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.

What would be the upside to such an approach?  I can see the
next-edition-of-ES-that-provides-decimal (my working assumption still
is "3.1" whatever that may be called, others may be understandably
skeptical) only providing a Decimal object, and with that addition the
language with respect to decimal being considered a steady state that
not need to be revisited in subsequent editions.

> * 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!).

I'd prefer if Decimal instances in ES were considered immutable and
automatically "interned".  By the latter, I simply mean that new
Decimal("1.0") === new Decimal("1.0").

> 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.

My assumption prior to the few days of discussion was that 1.0m was a
primitive.  Based on these discussions, making it be an object makes
sense to me.

> 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.

Agreed, that may be ok after all.

> 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 ;-).

That was previously still on my list of things to do.  Now it appears
that it is one less thing to do. :-)

>> 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.

Again, sorry for the typo.  I hope nobody is seriously considering
having the following be false, no matter what the value of
typeof(1.0m) is:

  1.0m == 1.00m

> /be

- Sam Ruby


More information about the Es-discuss mailing list