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