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

Sam Ruby rubys at
Tue Sep 23 18:16:26 PDT 2008

Brendan Eich wrote:
> 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.

At the present time, strictly equals is approximately the "Object.eq". 
There is no question that a.eq(b) => o[a] is o[b].

Permit me to be so bold as to propose a Gedanken Experiment?

Is it ever anticipated that future editions of ECMAScript will allow 
users to provide via multimethods alternative implementations for either 
double equals or triple equals?

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

Good summary.

> /be

- Sam Ruby

More information about the Es-discuss mailing list