Re: A DOM use case that can't be emulated with direct proxies
Le 14/12/2012 08:25, Brendan Eich a écrit : Mark S. Miller wrote: On Thu, Dec 13, 2012 at 7:05 PM, Brendan Eichbren...@secure.meer.net wrote: Boris Zbarsky pointed out on public-script-coord that window.location and window.document must be non-configurable _ab initio_, but perhaps this is achievable with direct proxies? This resolved into two suggestions, both consistent with ES5 and with direct proxies: * windows.document and window.location must refuse to be configured, but they can still claim to be configurable. ES5 purposely forbids only the opposite mismatch: They can't claim to be non-configurable but still change state in ways that violate that claim. * Allen suggested that these could be non-configurable getter-only accessor properties, To be more specific, [Unforgeable] properties would be described by non-configurable getter-only properties. window.location can be set by assignment to navigate to a new URL. location is [Unforgeable, PutForward], so it should be reflected as a non-configurable getter+setter according to WebIDL. Yet it appears in Chrome, Firefox, Opera, and Safari to be a writable data property. oh, web browsers and standards... There is indeed a pretty violent mismatch between WebIDL and reality, I guess. Specifically because of the behavior you're describing (assigning window.location having a behavior), location ought to be an accessor. What was the rationale that motivated all these browsers to go for data property? Is it still time to change this behavior? David In any event, it can't be a getter-only accessor. /be where the getter stays the same and the magic switching behavior is in the getter. (My words for Allen's suggestion) Either is fine. I like Allen's better. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
On 13 December 2012 19:21, Mark S. Miller erig...@google.com wrote: On Thu, Dec 13, 2012 at 1:12 AM, David Bruant bruan...@gmail.com wrote: As you say, to remain viable, it must be done quickly. From previous experience, I suggest that there's exactly one way to get quick universal deployment: add a test to test262 that fails when a browser's WindowProxy object violates this normative part of the ES5 spec. I feel such a test would rather belong to the HTML DOM. But either way, I agree. The spec that it violates is ES5.1. Therefore it will be uncontroversial to put such tests into test262. I have to strongly disagree here. By this argument, we could put in a test for any JS extension in the world that potentially violates proper ES semantics. I think test262 should test ECMA-262, nothing else. In particular, consider that test262 currently is a headless test, i.e. no browser needed, a shell like d8 or jsc is enough to run it. Putting in browser-specific tests would put a _huge_ burden on all kinds of automated testing environments running this suite. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
Le 14/12/2012 11:01, Andreas Rossberg a écrit : On 13 December 2012 19:21, Mark S. Miller erig...@google.com wrote: On Thu, Dec 13, 2012 at 1:12 AM, David Bruant bruan...@gmail.com wrote: As you say, to remain viable, it must be done quickly. From previous experience, I suggest that there's exactly one way to get quick universal deployment: add a test to test262 that fails when a browser's WindowProxy object violates this normative part of the ES5 spec. I feel such a test would rather belong to the HTML DOM. But either way, I agree. The spec that it violates is ES5.1. Therefore it will be uncontroversial to put such tests into test262. I have to strongly disagree here. By this argument, we could put in a test for any JS extension in the world that potentially violates proper ES semantics. I think test262 should test ECMA-262, nothing else. In particular, consider that test262 currently is a headless test, i.e. no browser needed, a shell like d8 or jsc is enough to run it. Putting in browser-specific tests would put a _huge_ burden on all kinds of automated testing environments running this suite. I still believe the tests belong to HTML DOM, but it wouldn't be absurd to test this inside of test262. The invariants are an ES5 device. I think it makes sense for ES5 to say we noticed that some platforms were defining host objects not respecting the invariants; here is how they were wrong. The invariants are a not-well-known and yet normative part of the spec. Offering some guidance in test262 on this part would be good I think. I would organize things the following way: inside of the /test/suite directory bestPractice/ ch06/ .. ch15/ intl402/ platformSpecific/ readme (explains why this directory is here and what the different subdirectories are for) webBrowser/ readme (to explain how to run each test) test1 ... testn And if different platforms use ES5, but do not conform, platformSpecific subdirectories can be added to test the non-conforming host objects on the different platforms. Each platform test can contain any sort of file, not just JS. For instance, in the case being discussed, it would make sense to create several HTML files some defining iframes, other defining iframe contents. d8 or jsc would just have to skip the platformSpecific directory. I think it's a decent trade-off to explain how invariants should work on self-objects without polluting the test suite. [cc'ing test262] David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
On Fri, Dec 14, 2012 at 2:43 AM, Andreas Rossberg rossb...@google.com wrote:
On 14 December 2012 06:46, John-David Dalton
john.david.dal...@gmail.com wrote:
Axel Rauschmayer:
Honest question: I have yet to see boxed values in practice. Are there any
real use cases?
See Modernizr:
https://github.com/Modernizr/Modernizr/blob/master/feature-detects/video.js#L23
I think not. And wrapping bools, like the above piece of code does, is
a particularly bad idea, because JS says
(Object(false) ? 1 : 2) === 1
Fortunately, I think that bit of code never returns Object(false),
because the `if` fails first, and just plain `false` is returned.
Really, since objects are truthy, `new Boolean(bool)` there could be
replaced with `{}`. Or, the whole body of the `if` could just be an
object literal.
Sam
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
+1. What Andreas said. On Friday, December 14, 2012, Andreas Rossberg wrote: On 13 December 2012 19:21, Mark S. Miller erig...@google.comjavascript:; wrote: On Thu, Dec 13, 2012 at 1:12 AM, David Bruant bruan...@gmail.comjavascript:; wrote: As you say, to remain viable, it must be done quickly. From previous experience, I suggest that there's exactly one way to get quick universal deployment: add a test to test262 that fails when a browser's WindowProxy object violates this normative part of the ES5 spec. I feel such a test would rather belong to the HTML DOM. But either way, I agree. The spec that it violates is ES5.1. Therefore it will be uncontroversial to put such tests into test262. I have to strongly disagree here. By this argument, we could put in a test for any JS extension in the world that potentially violates proper ES semantics. I think test262 should test ECMA-262, nothing else. In particular, consider that test262 currently is a headless test, i.e. no browser needed, a shell like d8 or jsc is enough to run it. Putting in browser-specific tests would put a _huge_ burden on all kinds of automated testing environments running this suite. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org javascript:; https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
Regarding what Andreas said and what Alex +1ed, we already have precedent. We already argued through this precedent in committee and agreed. I like David's suggestion about how to organize these tests. On Fri, Dec 14, 2012 at 5:22 AM, Alex Russell slightly...@google.comwrote: +1. What Andreas said. On Friday, December 14, 2012, Andreas Rossberg wrote: On 13 December 2012 19:21, Mark S. Miller erig...@google.com wrote: On Thu, Dec 13, 2012 at 1:12 AM, David Bruant bruan...@gmail.com wrote: As you say, to remain viable, it must be done quickly. From previous experience, I suggest that there's exactly one way to get quick universal deployment: add a test to test262 that fails when a browser's WindowProxy object violates this normative part of the ES5 spec. I feel such a test would rather belong to the HTML DOM. But either way, I agree. The spec that it violates is ES5.1. Therefore it will be uncontroversial to put such tests into test262. I have to strongly disagree here. By this argument, we could put in a test for any JS extension in the world that potentially violates proper ES semantics. I think test262 should test ECMA-262, nothing else. In particular, consider that test262 currently is a headless test, i.e. no browser needed, a shell like d8 or jsc is enough to run it. Putting in browser-specific tests would put a _huge_ burden on all kinds of automated testing environments running this suite. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
On 14 December 2012 16:54, Mark Miller erig...@gmail.com wrote: Regarding what Andreas said and what Alex +1ed, we already have precedent. We already argued through this precedent in committee and agreed. I like David's suggestion about how to organize these tests. Hm, unless you are talking about intl402, I wasn't aware of that. What's the precedent? If the non ES tests are separated properly then it's probably less of an issue, though I still prefer that such tests are under a different umbrella. Just to make clear that they are not actually testing ES engines. That is, I'd much rather have a structure like (modulo details of naming): estests/ test262/ ch*/ intl402/ platforms/ /Andreas On Fri, Dec 14, 2012 at 5:22 AM, Alex Russell slightly...@google.com wrote: +1. What Andreas said. On Friday, December 14, 2012, Andreas Rossberg wrote: On 13 December 2012 19:21, Mark S. Miller erig...@google.com wrote: On Thu, Dec 13, 2012 at 1:12 AM, David Bruant bruan...@gmail.com wrote: As you say, to remain viable, it must be done quickly. From previous experience, I suggest that there's exactly one way to get quick universal deployment: add a test to test262 that fails when a browser's WindowProxy object violates this normative part of the ES5 spec. I feel such a test would rather belong to the HTML DOM. But either way, I agree. The spec that it violates is ES5.1. Therefore it will be uncontroversial to put such tests into test262. I have to strongly disagree here. By this argument, we could put in a test for any JS extension in the world that potentially violates proper ES semantics. I think test262 should test ECMA-262, nothing else. In particular, consider that test262 currently is a headless test, i.e. no browser needed, a shell like d8 or jsc is enough to run it. Putting in browser-specific tests would put a _huge_ burden on all kinds of automated testing environments running this suite. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
No, the whole point of Number.isNaN is to provide a definitively test for NaN number values which cannot be tested for in the usual way using ===. The definitiveness of the test would be lost if other values such a Number wrapper instance also returned true when passed as the argument for Number.isNaN. Arguably, the Type test in the draft is redundant, but may be clarifying. If you wanted to test for NaN-ness of either Number values or Number wrappers then the appropriate thing would be to make isNaN an method of Number.prototype. Allen On Dec 13, 2012, at 7:19 PM, John-David Dalton wrote: I noticed that ES6 `Number.isNaN` checks `Type(number)` of Number, would it make sense to instead check that the [[BuiltinBrand]] is BuiltinNumberWrapper similar to `Array.isArray`'s check. This would also allow `Number.isNaN(Object(NaN))` to return `true`. Thoughts? - JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
No, the whole point of Number.isNaN is to provide a definitively test for NaN number values which cannot be tested for in the usual way using ===. Wat? This seems to be a good reason to allow `Object(NaN)` and use the NumberWrapper brand as it cannot be tested via the normal way of `myNaN !== myNaN`. On Fri, Dec 14, 2012 at 8:39 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: No, the whole point of Number.isNaN is to provide a definitively test for NaN number values which cannot be tested for in the usual way using ===. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
On Fri, Dec 14, 2012 at 8:36 AM, Andreas Rossberg rossb...@google.comwrote: On 14 December 2012 16:54, Mark Miller erig...@gmail.com wrote: Regarding what Andreas said and what Alex +1ed, we already have precedent. We already argued through this precedent in committee and agreed. I like David's suggestion about how to organize these tests. Hm, unless you are talking about intl402, I wasn't aware of that. What's the precedent? I will find it when I have time. If anyone else finds it first, please post a link. Thanks. If the non ES tests are separated properly then it's probably less of an issue, though I still prefer that such tests are under a different umbrella. Just to make clear that they are not actually testing ES engines. That is, I'd much rather have a structure like (modulo details of naming): estests/ test262/ ch*/ intl402/ platforms/ The violation is a violation of the normative ES-262 5.1 spec. Host objects as exposed to ES are part of the TCB, and constrained by the ES spec. The ES spec is does not just constrain ES engines. If you want to make a separate engines/ subdirectory of test262/ and move all the engine-only tests there, I would not object. But I also would not recommend bothering. /Andreas On Fri, Dec 14, 2012 at 5:22 AM, Alex Russell slightly...@google.com wrote: +1. What Andreas said. On Friday, December 14, 2012, Andreas Rossberg wrote: On 13 December 2012 19:21, Mark S. Miller erig...@google.com wrote: On Thu, Dec 13, 2012 at 1:12 AM, David Bruant bruan...@gmail.com wrote: As you say, to remain viable, it must be done quickly. From previous experience, I suggest that there's exactly one way to get quick universal deployment: add a test to test262 that fails when a browser's WindowProxy object violates this normative part of the ES5 spec. I feel such a test would rather belong to the HTML DOM. But either way, I agree. The spec that it violates is ES5.1. Therefore it will be uncontroversial to put such tests into test262. I have to strongly disagree here. By this argument, we could put in a test for any JS extension in the world that potentially violates proper ES semantics. I think test262 should test ECMA-262, nothing else. In particular, consider that test262 currently is a headless test, i.e. no browser needed, a shell like d8 or jsc is enough to run it. Putting in browser-specific tests would put a _huge_ burden on all kinds of automated testing environments running this suite. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Text by me above is hereby placed in the public domain Cheers, --MarkM -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Number.isNaN
Wat? This seems to be a good reason to allow `Object(NaN)` and use the NumberWrapper brand as it cannot be tested via the normal way of `myNaN !== myNaN`. But `myNaN === myNaN` is true if `myNaN = Object(NaN)`. Testing against the object is different. Nothing breaks. var myNaN = Object(NaN); [ 1, 3, myNaN ].indexOf(myNaN); // = 2 Works as expected. The only problem which occurs is when you're working with primitive NaN, in which case the only existing good ways to test for it are `x !== x` and `typeof x == 'number' isNaN(x)`. The purpose of `Number.isNaN` is to provide a way to test this case which is easier to read and understand. Note that if `x = Object(NaN)` both of these tests fail. Nathan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
But `myNaN === myNaN` is true if `myNaN = Object(NaN)`. That's my point. Normally testing for NaN can be done via `myNaN !== myNaN` but `Object(NaN)` throws a wrench in that. It would be great if there was 1 function that was able to detect NaN, instead of having libs step up and do it. -JDD On Fri, Dec 14, 2012 at 9:12 AM, Nathan Wall nathan.w...@live.com wrote: Wat? This seems to be a good reason to allow `Object(NaN)` and use the NumberWrapper brand as it cannot be tested via the normal way of `myNaN !== myNaN`. But `myNaN === myNaN` is true if `myNaN = Object(NaN)`. Testing against the object is different. Nothing breaks. var myNaN = Object(NaN); [ 1, 3, myNaN ].indexOf(myNaN); // = 2 Works as expected. The only problem which occurs is when you're working with primitive NaN, in which case the only existing good ways to test for it are `x !== x` and `typeof x == 'number' isNaN(x)`. The purpose of `Number.isNaN` is to provide a way to test this case which is easier to read and understand. Note that if `x = Object(NaN)` both of these tests fail. Nathan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
EcmaScript koan: NaN is NotANumber. NaN is a number. Object(NaN) is not a number. Thus, Object(NaN) isn't NotANumber. On Fri, Dec 14, 2012 at 9:22 AM, John-David Dalton john.david.dal...@gmail.com wrote: But `myNaN === myNaN` is true if `myNaN = Object(NaN)`. That's my point. Normally testing for NaN can be done via `myNaN !== myNaN` but `Object(NaN)` throws a wrench in that. It would be great if there was 1 function that was able to detect NaN, instead of having libs step up and do it. -JDD On Fri, Dec 14, 2012 at 9:12 AM, Nathan Wall nathan.w...@live.com wrote: Wat? This seems to be a good reason to allow `Object(NaN)` and use the NumberWrapper brand as it cannot be tested via the normal way of `myNaN !== myNaN`. But `myNaN === myNaN` is true if `myNaN = Object(NaN)`. Testing against the object is different. Nothing breaks. var myNaN = Object(NaN); [ 1, 3, myNaN ].indexOf(myNaN); // = 2 Works as expected. The only problem which occurs is when you're working with primitive NaN, in which case the only existing good ways to test for it are `x !== x` and `typeof x == 'number' isNaN(x)`. The purpose of `Number.isNaN` is to provide a way to test this case which is easier to read and understand. Note that if `x = Object(NaN)` both of these tests fail. Nathan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
That is deep. On Friday, December 14, 2012, Mark S. Miller wrote: EcmaScript koan: NaN is NotANumber. NaN is a number. Object(NaN) is not a number. Thus, Object(NaN) isn't NotANumber. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
On Fri, Dec 14, 2012 at 9:12 AM, Mark Miller erig...@gmail.com wrote: On Fri, Dec 14, 2012 at 8:36 AM, Andreas Rossberg rossb...@google.com wrote: On 14 December 2012 16:54, Mark Miller erig...@gmail.com wrote: Regarding what Andreas said and what Alex +1ed, we already have precedent. We already argued through this precedent in committee and agreed. I like David's suggestion about how to organize these tests. Hm, unless you are talking about intl402, I wasn't aware of that. What's the precedent? I will find it when I have time. If anyone else finds it first, please post a link. Thanks. http://hg.ecmascript.org/tests/test262/file/c84161250e66/test/suite/ch15/15.2/15.2.3/15.2.3.6/S15.2.3.6_A1.js If the non ES tests are separated properly then it's probably less of an issue, though I still prefer that such tests are under a different umbrella. Just to make clear that they are not actually testing ES engines. That is, I'd much rather have a structure like (modulo details of naming): estests/ test262/ ch*/ intl402/ platforms/ The violation is a violation of the normative ES-262 5.1 spec. Host objects as exposed to ES are part of the TCB, and constrained by the ES spec. The ES spec is does not just constrain ES engines. If you want to make a separate engines/ subdirectory of test262/ and move all the engine-only tests there, I would not object. But I also would not recommend bothering. /Andreas On Fri, Dec 14, 2012 at 5:22 AM, Alex Russell slightly...@google.com wrote: +1. What Andreas said. On Friday, December 14, 2012, Andreas Rossberg wrote: On 13 December 2012 19:21, Mark S. Miller erig...@google.com wrote: On Thu, Dec 13, 2012 at 1:12 AM, David Bruant bruan...@gmail.com wrote: As you say, to remain viable, it must be done quickly. From previous experience, I suggest that there's exactly one way to get quick universal deployment: add a test to test262 that fails when a browser's WindowProxy object violates this normative part of the ES5 spec. I feel such a test would rather belong to the HTML DOM. But either way, I agree. The spec that it violates is ES5.1. Therefore it will be uncontroversial to put such tests into test262. I have to strongly disagree here. By this argument, we could put in a test for any JS extension in the world that potentially violates proper ES semantics. I think test262 should test ECMA-262, nothing else. In particular, consider that test262 currently is a headless test, i.e. no browser needed, a shell like d8 or jsc is enough to run it. Putting in browser-specific tests would put a _huge_ burden on all kinds of automated testing environments running this suite. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Text by me above is hereby placed in the public domain Cheers, --MarkM -- Text by me above is hereby placed in the public domain Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
David Bruant wrote: Le 14/12/2012 08:25, Brendan Eich a écrit : window.location can be set by assignment to navigate to a new URL. location is [Unforgeable, PutForward], so it should be reflected as a non-configurable getter+setter according to WebIDL. That would be correct -- and nice, I agree. Yet it appears in Chrome, Firefox, Opera, and Safari to be a writable data property. oh, web browsers and standards... There is indeed a pretty violent mismatch between WebIDL and reality, I guess. Specifically because of the behavior you're describing (assigning window.location having a behavior), location ought to be an accessor. What was the rationale that motivated all these browsers to go for data property? Is it still time to change this behavior? Let's not make the standards-are-prior-to-implementations mistake. All this came from Netscape 2, JS1. It got cloned by IE and other browsers. It mutated and was not standardized until a decade later, in HTML5 and then DOM4 -- and WebIDL is an even later (still not REC, it's in CR if I recall correctly) standard. Nevertheless, since ES5-standard reflection is new, I doubt anyone cares that location appears to be a data property. It should be an accessor. But it needs to be non-configurable, so we still have a problem -- or do we? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
John-David Dalton wrote: But `myNaN === myNaN` is true if `myNaN = Object(NaN)`. That's my point. Normally testing for NaN can be done via `myNaN !== myNaN` but `Object(NaN)` throws a wrench in that. It would be great if there was 1 function that was able to detect NaN, instead of having libs step up and do it. Why? Who wraps NaN? Your modernizr true-wrapping Boolean example is both a WTFJS moment, easily avoided by using a truthy object as Sam pointed out, and nothing to do with NaN. /be -JDD On Fri, Dec 14, 2012 at 9:12 AM, Nathan Wall nathan.w...@live.com mailto:nathan.w...@live.com wrote: Wat? This seems to be a good reason to allow `Object(NaN)` and use the NumberWrapper brand as it cannot be tested via the normal way of `myNaN !== myNaN`. But `myNaN === myNaN` is true if `myNaN = Object(NaN)`. Testing against the object is different. Nothing breaks. var myNaN = Object(NaN); [ 1, 3, myNaN ].indexOf(myNaN); // = 2 Works as expected. The only problem which occurs is when you're working with primitive NaN, in which case the only existing good ways to test for it are `x !== x` and `typeof x == 'number' isNaN(x)`. The purpose of `Number.isNaN` is to provide a way to test this case which is easier to read and understand. Note that if `x = Object(NaN)` both of these tests fail. Nathan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Number.isNaN
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Nathan Wall [nathan.w...@live.com] Sent: Friday, December 14, 2012 13:34 On another note, I do sort of wonder why `Number.isNaN` is coming into the language now at the same time as the `is` operator and `Object.is`. It seems teaching people (and getting them to remember long-term) the nuances of `isNaN` and `Number.isNaN` will be more difficult than just teaching people to use `x is NaN` in ES6 or `Object.is(x, NaN)` in an ES3/5 + ES6 shims environment. `is` operator is dead :( :( :( (Someone want to find a link to the minutes that killed it? I keep having to correct people on this.) There's not an `isNull` or `isUndefined`. The only reason `isNaN` was needed was because `===` didn't work with `NaN`, but `is` does. This is pretty reasonable, actually. The only argument I can see is that `array.filter(Number.isNaN)` is shorter than `array.filter(x = Object.is(x, NaN))`. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
Bendan Eich wrote:
Your modernizr true-wrapping Boolean example is both a WTFJS moment,
easily avoided by using a truthy object as Sam pointed out, and nothing to
do with NaN.
The Modernizr example was in response to Axel's request for an example of
boxed values being used in real world projects.
I love how the thread got sidetracked by that one ;D
Popular libs like jQuery, Dojo, MooTools, Prototype, and Underscore have
`isXyz` methods or equivalents that equate boxed and unboxed values as
similar:
For example:
Underscore `_.isString('hi')` and `_.isString(Object('hi'))` both return
`true` also `_.isEqual('hi', Object('hi'))` returns `true`
MooTools `typeOf('hi')` and `typeOf(Object('hi'))` both return 'string'
Prototype `Object.isString('hi')` and `Object.isString(Object('hi'))` both
return `true`
jQuery `$.type('hi')` and `$.type(Object('hi'))` both return 'string'
Dojo `dojo.isString('hi')` and `dojo.isString(Object('hi'))` return `true`
`Object(NaN)` is edge case, but lots of things in the spec are edge (`-0`
anyone).
Because the majority of libs treat boxed and unboxed alike in their `isXyz`
I think the spec should follow.
On Fri, Dec 14, 2012 at 10:21 AM, Brendan Eich bren...@mozilla.com wrote:
John-David Dalton wrote:
But `myNaN === myNaN` is true if `myNaN = Object(NaN)`.
That's my point. Normally testing for NaN can be done via `myNaN !==
myNaN` but `Object(NaN)` throws a wrench in that.
It would be great if there was 1 function that was able to detect NaN,
instead of having libs step up and do it.
Why? Who wraps NaN? Your modernizr true-wrapping Boolean example is both a
WTFJS moment, easily avoided by using a truthy object as Sam pointed out,
and nothing to do with NaN.
/be
-JDD
On Fri, Dec 14, 2012 at 9:12 AM, Nathan Wall nathan.w...@live.commailto:
nathan.w...@live.com wrote:
Wat? This seems to be a good reason to allow `Object(NaN)` and
use the
NumberWrapper brand as it cannot be tested via the normal way of
`myNaN !== myNaN`.
But `myNaN === myNaN` is true if `myNaN = Object(NaN)`. Testing
against the object is different. Nothing breaks.
var myNaN = Object(NaN);
[ 1, 3, myNaN ].indexOf(myNaN); // = 2
Works as expected. The only problem which occurs is when you're
working with primitive NaN, in which case the only existing good
ways to test for it are `x !== x` and `typeof x == 'number'
isNaN(x)`. The purpose of `Number.isNaN` is to provide a way to
test this case which is easier to read and understand. Note that
if `x = Object(NaN)` both of these tests fail.
Nathan
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Number.isNaN
On another note, I do sort of wonder why `Number.isNaN` is coming into the language now at the same time as the `is` operator and `Object.is`. It seems teaching people (and getting them to remember long-term) the nuances of `isNaN` and `Number.isNaN` will be more difficult than just teaching people to use `x is NaN` in ES6 or `Object.is(x, NaN)` in an ES3/5 + ES6 shims environment. `is` operator is dead :( :( :( That is sad indeed :( Nathan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
On Dec 14, 2012, at 10:45 AM, Domenic Denicola wrote: From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Nathan Wall [nathan.w...@live.com] Sent: Friday, December 14, 2012 13:34 On another note, I do sort of wonder why `Number.isNaN` is coming into the language now at the same time as the `is` operator and `Object.is`. It seems teaching people (and getting them to remember long-term) the nuances of `isNaN` and `Number.isNaN` will be more difficult than just teaching people to use `x is NaN` in ES6 or `Object.is(x, NaN)` in an ES3/5 + ES6 shims environment. `is` operator is dead :( :( :( (Someone want to find a link to the minutes that killed it? I keep having to correct people on this.) I may be wrong, but I don't think it was ever formally killed by TC39. I was discussed here where the consensus was to kill it, but I don't recall an actual discussion at a TC39 meeting. That's why I haven't deleted the is operator from the draft yet. It's something I keep intending to verify at a meeting, but it keeps getting lost in the weeds. BTW, I think there are probably other related issues that need to be discussed/resolved at that level. For example, is SameValue really want we want for Map/Set equivalence (the -0 different from +0 issue), did we agree to parameterize the equivalance operator for Map/Set?, and the question about the need for Number.isNaN if we have Object.is available. Allen There's not an `isNull` or `isUndefined`. The only reason `isNaN` was needed was because `===` didn't work with `NaN`, but `is` does. This is pretty reasonable, actually. The only argument I can see is that `array.filter(Number.isNaN)` is shorter than `array.filter(x = Object.is(x, NaN))`. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
On Fri, Dec 14, 2012 at 10:19 AM, Brendan Eich bren...@mozilla.com wrote: David Bruant wrote: Le 14/12/2012 08:25, Brendan Eich a écrit : window.location can be set by assignment to navigate to a new URL. location is [Unforgeable, PutForward], so it should be reflected as a non-configurable getter+setter according to WebIDL. That would be correct -- and nice, I agree. Yet it appears in Chrome, Firefox, Opera, and Safari to be a writable data property. oh, web browsers and standards... There is indeed a pretty violent mismatch between WebIDL and reality, I guess. Specifically because of the behavior you're describing (assigning window.location having a behavior), location ought to be an accessor. What was the rationale that motivated all these browsers to go for data property? Is it still time to change this behavior? Let's not make the standards-are-prior-to-implementations mistake. All this came from Netscape 2, JS1. It got cloned by IE and other browsers. It mutated and was not standardized until a decade later, in HTML5 and then DOM4 -- and WebIDL is an even later (still not REC, it's in CR if I recall correctly) standard. Nevertheless, since ES5-standard reflection is new, I doubt anyone cares that location appears to be a data property. It should be an accessor. But it needs to be non-configurable, so we still have a problem -- or do we? AFAICT, a non-configurable accessor fits all the constraints. /be -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
Speaking of SameValue, it's unnecessary in many/most of the places it's used in the spec. Like in IsEquivelentDescriptor the only comparison that needs to use SameValue is comparing the [[Value]] field. On Fri, Dec 14, 2012 at 2:02 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Dec 14, 2012, at 10:45 AM, Domenic Denicola wrote: From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Nathan Wall [nathan.w...@live.com] Sent: Friday, December 14, 2012 13:34 On another note, I do sort of wonder why `Number.isNaN` is coming into the language now at the same time as the `is` operator and `Object.is`. It seems teaching people (and getting them to remember long-term) the nuances of `isNaN` and `Number.isNaN` will be more difficult than just teaching people to use `x is NaN` in ES6 or `Object.is(x, NaN)` in an ES3/5 + ES6 shims environment. `is` operator is dead :( :( :( (Someone want to find a link to the minutes that killed it? I keep having to correct people on this.) I may be wrong, but I don't think it was ever formally killed by TC39. I was discussed here where the consensus was to kill it, but I don't recall an actual discussion at a TC39 meeting. That's why I haven't deleted the is operator from the draft yet. It's something I keep intending to verify at a meeting, but it keeps getting lost in the weeds. BTW, I think there are probably other related issues that need to be discussed/resolved at that level. For example, is SameValue really want we want for Map/Set equivalence (the -0 different from +0 issue), did we agree to parameterize the equivalance operator for Map/Set?, and the question about the need for Number.isNaN if we have Object.is available. Allen There's not an `isNull` or `isUndefined`. The only reason `isNaN` was needed was because `===` didn't work with `NaN`, but `is` does. This is pretty reasonable, actually. The only argument I can see is that `array.filter(Number.isNaN)` is shorter than `array.filter(x = Object.is(x, NaN))`. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
Domenic Denicola wrote: From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Nathan Wall [nathan.w...@live.com] Sent: Friday, December 14, 2012 13:34 On another note, I do sort of wonder why `Number.isNaN` is coming into the language now at the same time as the `is` operator and `Object.is`. It seems teaching people (and getting them to remember long-term) the nuances of `isNaN` and `Number.isNaN` will be more difficult than just teaching people to use `x is NaN` in ES6 or `Object.is(x, NaN)` in an ES3/5 + ES6 shims environment. `is` operator is dead :( :( :( Restricted productions creating new operators may be at risk (Allen's right, we haven't had an orderly decision in TC39 on this point), but Object.is or Object.isSameValue is definitely not dead. Allen's right too that we have some disagreement on the use of SameValue under the hood in Map and Set. /be (Someone want to find a link to the minutes that killed it? I keep having to correct people on this.) There's not an `isNull` or `isUndefined`. The only reason `isNaN` was needed was because `===` didn't work with `NaN`, but `is` does. This is pretty reasonable, actually. The only argument I can see is that `array.filter(Number.isNaN)` is shorter than `array.filter(x = Object.is(x, NaN))`. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
Mark S. Miller wrote: Nevertheless, since ES5-standard reflection is new, I doubt anyone cares that location appears to be a data property. It should be an accessor. But it needs to be non-configurable, so we still have a problem -- or do we? AFAICT, a non-configurable accessor fits all the constraints. Great! Let's do that then. Can someone bring this to public-script-coord or where-ever else might be the best venue for getting implementors on board? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
I apologize for the duplicate post, but I think my reply got lost in its
formatting.
The Modernizr example was in response to Axel's request for an example of
boxed values being used in real world projects.
Popular libs like jQuery, Dojo, MooTools, Prototype, and Underscore have
`isXyz` methods or equivalents that treat boxed and unboxed values as like:
For example:
Underscore `_.isString('hi')` and `_.isString(Object('hi'))` both return
`true` also `_.isEqual('hi', Object('hi'))` returns `true`
MooTools `typeOf('hi')` and `typeOf(Object('hi'))` both return 'string'
Prototype `Object.isString('hi')` and `Object.isString(Object('hi'))` both
return `true`
jQuery `$.type('hi')` and `$.type(Object('hi'))` both return 'string'
Dojo `dojo.isString('hi')` and `dojo.isString(Object('hi'))` return `true`
`Object(NaN)` is edge case, but lots of things in the spec are edge (`-0`
anyone).
Because the majority of libs treat boxed and unboxed the same in their
`isXyz` I think it's natural for the spec to follow in the case of
`Number.isNaN`.
Thanks,
-JDD
On Fri, Dec 14, 2012 at 12:01 PM, Brendan Eich bren...@mozilla.com wrote:
Domenic Denicola wrote:
From: es-discuss-boun...@mozilla.org
[es-discuss-bounces@mozilla.**orges-discuss-boun...@mozilla.org]
on behalf of Nathan Wall [nathan.w...@live.com]
Sent: Friday, December 14, 2012 13:34
On another note, I do sort of wonder why `Number.isNaN` is coming into
the language now at the same time as the `is` operator and `Object.is`. It
seems teaching people (and getting them to remember long-term) the nuances
of `isNaN` and `Number.isNaN` will be more difficult than just teaching
people to use `x is NaN` in ES6 or `Object.is(x, NaN)` in an ES3/5 + ES6
shims environment.
`is` operator is dead :( :( :(
Restricted productions creating new operators may be at risk (Allen's
right, we haven't had an orderly decision in TC39 on this point), but
Object.is or Object.isSameValue is definitely not dead.
Allen's right too that we have some disagreement on the use of SameValue
under the hood in Map and Set.
/be
(Someone want to find a link to the minutes that killed it? I keep having
to correct people on this.)
There's not an `isNull` or `isUndefined`. The only reason `isNaN` was
needed was because `===` didn't work with `NaN`, but `is` does.
This is pretty reasonable, actually. The only argument I can see is that
`array.filter(Number.isNaN)` is shorter than `array.filter(x =
Object.is(x, NaN))`.
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
This boxed-primitive equation is a sore point, and perhaps some API
should be standardized, but Number.isNaN is not that API. That's point
#1, please ack it: we must have a predicate that applies only to true
NaN primitives.
Point #2 is that we haven't heard the demand for such APIs until now.
That means no ES6 late exception-granting, and for a Harmony strawman
(ES7 or later) we would need to study the use-cases and exactly API
details more closely. Mostly the use-cases, to see whether something
important happens in the context of a given library or its folkways
that won't -- or should not -- happen in the standardized core language.
Not all libraries have cowpaths that we want to pave. For one thing,
libraries conflict. For another, some have design flaws.
/be
John-David Dalton wrote:
I apologize for the duplicate post, but I think my reply got lost in
its formatting.
The Modernizr example was in response to Axel's request for an example
of boxed values being used in real world projects.
Popular libs like jQuery, Dojo, MooTools, Prototype, and Underscore
have `isXyz` methods or equivalents that treat boxed and unboxed
values as like:
For example:
Underscore `_.isString('hi')` and `_.isString(Object('hi'))` both
return `true` also `_.isEqual('hi', Object('hi'))` returns `true`
MooTools `typeOf('hi')` and `typeOf(Object('hi'))` both return 'string'
Prototype `Object.isString('hi')` and `Object.isString(Object('hi'))`
both return `true`
jQuery `$.type('hi')` and `$.type(Object('hi'))` both return 'string'
Dojo `dojo.isString('hi')` and `dojo.isString(Object('hi'))` return `true`
`Object(NaN)` is edge case, but lots of things in the spec are edge
(`-0` anyone).
Because the majority of libs treat boxed and unboxed the same in their
`isXyz` I think it's natural for the spec to follow in the case of
`Number.isNaN`.
Thanks,
-JDD
On Fri, Dec 14, 2012 at 12:01 PM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Domenic Denicola wrote:
From: es-discuss-boun...@mozilla.org
mailto:es-discuss-boun...@mozilla.org
[es-discuss-boun...@mozilla.org
mailto:es-discuss-boun...@mozilla.org] on behalf of
Nathan Wall [nathan.w...@live.com
mailto:nathan.w...@live.com]
Sent: Friday, December 14, 2012 13:34
On another note, I do sort of wonder why `Number.isNaN` is
coming into the language now at the same time as the `is`
operator and `Object.is`. It seems teaching people (and
getting them to remember long-term) the nuances of `isNaN`
and `Number.isNaN` will be more difficult than just
teaching people to use `x is NaN` in ES6 or `Object.is(x,
NaN)` in an ES3/5 + ES6 shims environment.
`is` operator is dead :( :( :(
Restricted productions creating new operators may be at risk
(Allen's right, we haven't had an orderly decision in TC39 on this
point), but Object.is or Object.isSameValue is definitely not dead.
Allen's right too that we have some disagreement on the use of
SameValue under the hood in Map and Set.
/be
(Someone want to find a link to the minutes that killed it? I
keep having to correct people on this.)
There's not an `isNull` or `isUndefined`. The only reason
`isNaN` was needed was because `===` didn't work with
`NaN`, but `is` does.
This is pretty reasonable, actually. The only argument I can
see is that `array.filter(Number.isNaN)` is shorter than
`array.filter(x = Object.is(x, NaN))`.
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
On Fri, Dec 14, 2012 at 2:02 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Dec 14, 2012, at 10:45 AM, Domenic Denicola wrote: From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Nathan Wall [nathan.w...@live.com] Sent: Friday, December 14, 2012 13:34 On another note, I do sort of wonder why `Number.isNaN` is coming into the language now at the same time as the `is` operator and `Object.is`. It seems teaching people (and getting them to remember long-term) the nuances of `isNaN` and `Number.isNaN` will be more difficult than just teaching people to use `x is NaN` in ES6 or `Object.is(x, NaN)` in an ES3/5 + ES6 shims environment. `is` operator is dead :( :( :( (Someone want to find a link to the minutes that killed it? I keep having to correct people on this.) I may be wrong, but I don't think it was ever formally killed by TC39. I was discussed here where the consensus was to kill it, but I don't recall an actual discussion at a TC39 meeting. That's why I haven't deleted the is operator from the draft yet. It's something I keep intending to verify at a meeting, but it keeps getting lost in the weeds. Confirmed. There is no such discussion on record from a TC39 meeting. Someone said out loud at the last meeting but it never made it to the agenda. I will formally add it to the agenda for January Rick BTW, I think there are probably other related issues that need to be discussed/resolved at that level. For example, is SameValue really want we want for Map/Set equivalence (the -0 different from +0 issue), did we agree to parameterize the equivalance operator for Map/Set?, and the question about the need for Number.isNaN if we have Object.is available. ps. These too. Allen There's not an `isNull` or `isUndefined`. The only reason `isNaN` was needed was because `===` didn't work with `NaN`, but `is` does. This is pretty reasonable, actually. The only argument I can see is that `array.filter(Number.isNaN)` is shorter than `array.filter(x = Object.is(x, NaN))`. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A DOM use case that can't be emulated with direct proxies
Le 14/12/2012 19:04, Mark S. Miller a écrit : On Fri, Dec 14, 2012 at 9:12 AM, Mark Miller erig...@gmail.com wrote: On Fri, Dec 14, 2012 at 8:36 AM, Andreas Rossberg rossb...@google.com wrote: On 14 December 2012 16:54, Mark Miller erig...@gmail.com wrote: Regarding what Andreas said and what Alex +1ed, we already have precedent. We already argued through this precedent in committee and agreed. I like David's suggestion about how to organize these tests. Hm, unless you are talking about intl402, I wasn't aware of that. What's the precedent? I will find it when I have time. If anyone else finds it first, please post a link. Thanks. http://hg.ecmascript.org/tests/test262/file/c84161250e66/test/suite/ch15/15.2/15.2.3/15.2.3.6/S15.2.3.6_A1.js Yes, this probably belongs somewhere else that the ch15 directory. For any other ECMAScript 5.1 implementation, there is no particular reason to consider the document global differently than any other. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
