Le 13/12/2012 00:51, Mark S. Miller a écrit :
On Wed, Dec 12, 2012 at 11:19 AM, David Bruant bruan...@gmail.com wrote:
[...]
* change the behavior of WindowProxy instances when it comes to doing things
that would commit them to eternal invariants to throw instead of forwarding.
This solution
On Wed, Dec 12, 2012 at 6:08 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Wed, Dec 12, 2012 at 1:59 AM, Axel Rauschmayer a...@rauschma.dewrote:
I would still love to have something like that in ES6 (loosely similar to
String.prototype.repeat). Once you have that, you can e.g. use
Great!
Is there already a planned test402 initiative (similar to test262)?
Regards,
Alexandre
On 12 déc. 2012, at 19:28, Norbert Lindenberg wrote:
István has informed me that the Ecma General Assembly today unanimously
approved ECMA-402, ECMAScript Internationalization API Specification.
On Thu, Dec 13, 2012 at 4:14 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
[ ...Array(8) ].map( (v, i) = 1 i )
That's awesome, check it out:
http://traceur-compiler.googlecode.com/git/demo/repl.html#%20%5B%20...Array(8)%20%5D.map(%20(v%2C%20i)%20%3D%3E%201%20%3C%3C%20i%20)
ECMAScript 5.1 does not syntactically permit a FunctionDeclaration to directly
appear nested within a Block. The semantics provided by the specification are
those for a function declaration at the top level of a function. The only
standard way to evaluate a function declaration within a
Allen Wirfs-Brock wrote:
Some implementations bind the function name scoped to the block others bind
the name scoped to the enclosing function.
Detailed aside: no standard implementation actually binds to a block
scope (yet -- this is proposed for ES6 and implementations are
appearing,
Hi Alexandre,
Yes, there is an initial set of tests. It currently is part of test262 because
it uses the test262 harness:
http://test262.ecmascript.org/testcases_intl402.html
http://hg.ecmascript.org/tests/test262/file/53c4ade82d14/test/suite/intl402
Regards,
Norbert
On Dec 13, 2012, at 1:50
On Thu, Dec 13, 2012 at 1:12 AM, David Bruant bruan...@gmail.com wrote:
I think this is the only viable solution.
Ok. What do you think of the idea of different handlers based on context?
[1]
[1] Last point of
https://mail.mozilla.org/pipermail/es-discuss/2012-December/027092.html
Only if
Something I just posted in the public-script-coord thread bears repeating here:
A single invariant-violating object can be leveraged by direct proxies
to create any number of other objects that also violate invariants.
___
es-discuss mailing list
On Thu, Dec 13, 2012 at 11:47 AM, Jason Orendorff jason.orendo...@gmail.com
wrote:
This target, even if dummy, is the one that will be used for invariants
checks. You can't get away from this by design. This is one of the most
important part of the direct proxies design.
Even if you switch
Le 13/12/2012 20:47, Jason Orendorff a écrit :
On Wed, Dec 12, 2012 at 3:44 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 12/12/2012 22:30, Kevin Reid a écrit :
The JS runtime won't know that the proxy has anything to do with
the actual Window instance.
On Thu, Dec 13, 2012 at 2:58 PM, David Bruant bruan...@gmail.com wrote:
Le 13/12/2012 20:47, Jason Orendorff a écrit :
David: https://gist.github.com/4279162
I think this is what Kevin has in mind. Note in particular that the target
of the Proxy is just a dummy object, and the handler
Kevin Reid wrote:
(2) the proxy has to pretend that all inherited properties are
actually own,
It strikes me that we need this for window objects anyway, to resolve
https://bugs.ecmascript.org/show_bug.cgi?id=78
___
es-discuss mailing list
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
On Thu, Dec 13, 2012 at 7:05 PM, Brendan Eich bren...@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,
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org]
On Behalf Of John-David Dalton
Subject: Number.isNaN
I noticed that ES6 `Number.isNaN` checks `Type(number)` of Number, would it
make sense to instead check that the [[BuiltinBrand]] is
BuiltinNumberWrapper
On Thu, Dec 13, 2012 at 7:50 PM, Luke Hoban lu...@microsoft.com wrote:
From: es-discuss-boun...@mozilla.org
[mailto:es-discuss-boun...@mozilla.org] On Behalf Of John-David Dalton
Subject: Number.isNaN
I noticed that ES6 `Number.isNaN` checks `Type(number)` of Number, would
it make sense
The current draft spec [0] uses a ToNumber coercion and checks whether
this results is NaN. So Number.isNaN(Object(NaN)) will return true.
Global's isNaN uses ToNumber, but Number.isNaN doesn't do it because type
coercion makes confused result, such as `isNaN(Object(NaN))` = true [0]
So
From: Mark S. Miller [mailto:erig...@google.com]
In that case, the current spec is wrong. The purpose of introducing
Number.isNaN is to repair the following bug in the global isNaN:
isNaN(foo) // returns true
Indeed, as Yusuke noted on the other reply, I referred to the wrong
Yap yap, so thoughts on `BuiltinNumberWrapper` instead of `Type(…)`? It
would still prevent the global `isNaN('foo')` confusion. Though
`Object.is(NaN, Object(NaN))` currently returns `false` too. Was this just
an oversight? I know `Object(NaN)` is totally edge case but it still has
the brand of
Honest question: I have yet to see boxed values in practice. Are there any real
use cases?
[[[Sent from a mobile device. Please forgive brevity and typos.]]]
Dr. Axel Rauschmayer
a...@rauschma.de
Home: http://rauschma.de
Blog: http://2ality.com
On 14.12.2012, at 05:18, Luke Hoban
On Thu, Dec 13, 2012 at 8:25 PM, John-David Dalton
john.david.dal...@gmail.com wrote:
Yap yap, so thoughts on `BuiltinNumberWrapper` instead of `Type(…)`? It
would still prevent the global `isNaN('foo')` confusion. Though
`Object.is(NaN, Object(NaN))` currently returns `false` too. Was this
No. Object.is correctly reports that these are different.
Ah yap, I've had my head in lib code for a while. I'm used to the behavior
of `_.isEqual(3, Object(3)); // = true`
but you're right the current behavior of `Object.is(3, Object(3)); //
false` so yap it makes sense that it's that way for
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
-JDD
On Thu, Dec 13, 2012 at 8:26 PM, Axel Rauschmayer a...@rauschma.de wrote:
Honest question: I have
David Bruant wrote:
Le 12/12/2012 21:42, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 12:35 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
I was a bit too strong in my statement, sorry. Let me rephrase:
the internal [[Target]] can't be changed, but a proxy can
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
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
27 matches
Mail list logo
