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
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:
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
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:
+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
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
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
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
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
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
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 =
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
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
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
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.
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
29 matches
Mail list logo
