ES3.1 Draft: 22 Sep 2008 "Redmond" version available

Brendan Eich brendan at mozilla.org
Tue Sep 23 15:34:47 PDT 2008


On Sep 23, 2008, at 1:45 PM, Waldemar Horwat wrote:

> Sam Ruby wrote:
>> One minor request: statements like "breaks arrays" are less helpful
>> than specific ECMAScript statements which would fail; better yet  
>> would
>> be citing specific deployed code that would fail.
>
> I already gave specific examples of this and we've had extensive  
> discussions of them.  I don't like beating a dead horse any more  
> than necessary.


The horse must not be dead. The question is: should a === b imply o 
[a] and o[b] refer to the same property, for any object o (modulo the  
spec bug that David Jones pointed out whereby 5e-324 could be  
converted to strings such as "3e-324" and "7e-324").

Sam seems to think a === b should not imply o[a] and o[b] refer to  
the same property (double-cited text is from Jason Orendorff):

> > Well, the intuition is that two equal numbers should index the same
> > property.  This is an invariant in ES3 and it makes a lot of sense.
>
> Correct me if I'm wrong, but the intuition would more properly be  
> based
> on string equality, and not numeric equality.  As an example, how many
> properties would the following produce, with an conformant
> implementation of ES3?
>
> var a = [];
> a['0.0'] = "first";
> a[0.0] = "second";  // a second property
> a['0'] = "third";   // replaces *second* property

The intuition depends on string equality and ToString in addition to  
numeric equality. But it turns out that a === b for any numbers a and  
b implies ToString(a) === ToString(b) (except, again, for the very  
small numbers David Jones pointed out).

But Sam's decimal implementation has 1.1m === 1.10m.

So the precise issue with "breaks arrays" is the proposal from Sam  
and Mike that ToString on a decimal preserve scale digits (I hope I'm  
using the right term). That breaks the a === b => o[a] is o[b] rule  
that exists today (modulo tiny values) for numbers a and b, when  
extended to decimals a and b.


> Intuition is a very tricky thing.  Place the following in front of any
> third grader, and tell me what they will write below the line.
>
>
>     1 . 0 5
>   + 2 . 0 5
>   _________


Of course the result should be 3.10 on paper, but this does not say  
that ToString applied to decimal must preserve scale digits.

One alternative is to distinguish the operation used when computing a  
property name from the ToString used everywhere else, and make the  
former lose scale digits while the latter preserves them. There's no  
doubt a 754r method for converting to string without trailing zeroes  
or otherwise preserving scale (those funny exponents Waldemar decried).

If we did this, we would have to complicate the spec by adding a  
special case to its computed property name logic. And users wishing  
to mimick it with explicit conversion to a string would not be able  
to use String(d) or "" + d -- they would have to call the other method.

/be


More information about the Es-discuss mailing list