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