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 _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
