On 12/4/14 11:49 AM, Mark S. Miller wrote:
On Thu, Dec 4, 2014 at 2:58 AM, Boris Zbarsky bzbar...@mit.edu wrote:
OK. What do we do if we discover that throwing from the defineProperty call
with a non-configurable property descriptor is not web-compatible?
What we always do
So just for the
Yehuda and I just talked about this code and realized that we can allow
this code to proceed on the success path without violating the invariants.
However, this analysis reveals that the intent stated in the comment is
unwarranted, but even that intent can be adequately honored in the scenario
of
On 28 Jan 2015, at 00:06, Brendan Eich bren...@mozilla.org wrote:
Axel Rauschmayer wrote:
It may make sense to add them. Their identifiers would have to be as
unambiguous as possible, e.g. URIs such as
http://ecmascript.org/symbol/foo;.
Symbol.iterator and the other well-known symbols
On 1/27/15 4:44 PM, Mark S. Miller wrote:
Since the WindowProxy is not a Proxy, or more relevantly, even if it
were a Proxy, the underlying Window is not its target, we can even do
the following:
When the WindowProxy sees the defineProperty with the omitted
configurable: and determines that the
They are not - if they were, then adding a new well-known symbol like
Symbol.foo would fail if anyone had code that did `Symbol.for('foo')`. (I
have no idea if that is the reason, but certainly that's a reason not to
make them available via the registry)
On Tue, Jan 27, 2015 at 2:32 PM, Cyrus
Hi esdiscuss. A couple more questions.
1) Are the built-in symbols (like ‘Symbol.iterator’) in the
GlobalSymbolRegsitry?
2) If so, what are their keys? i.e. how would one reach Symbol.iterator
using Symbol.for(…)?
Thanks!
-- Cyrus
From: Kevin Smith
Axel Rauschmayer wrote:
So there's no need for this
There is one use case (admittedly a rather hypothetical one):
serializing the Symbol.* symbols to a text format (e.g. an encoding in
JSON).
Symbols that user-code puts into the registry do not serialize this way,
so why should the
It may make sense to add them. Their identifiers would have to be as
unambiguous as possible, e.g. URIs such as http://ecmascript.org/symbol/foo
http://ecmascript.org/symbol/foo.
On 27 Jan 2015, at 23:55, Jordan Harband ljh...@gmail.com wrote:
They are not - if they were, then adding a new
Axel Rauschmayer wrote:
It may make sense to add them. Their identifiers would have to be as
unambiguous as possible, e.g. URIs such as
http://ecmascript.org/symbol/foo;.
Symbol.iterator and the other well-known symbols are self-same in all
connected realms. See
Mark S. Miller wrote:
The reason why the intent is unwarranted is that the descriptor omits
configurable: rather than explicitly saying configurable: true. If
the owner object already has a configurable own property of the same
name, then a defineProperty where the configurable: is omitted
On Tue, Jan 27, 2015 at 9:45 PM, Mark S. Miller erig...@google.com wrote:
On Tue, Jan 27, 2015 at 5:53 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/27/15 4:44 PM, Mark S. Miller wrote:
Since the WindowProxy is not a Proxy, or more relevantly, even if it
were a Proxy, the underlying
On Tue, Jan 27, 2015 at 5:53 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/27/15 4:44 PM, Mark S. Miller wrote:
Since the WindowProxy is not a Proxy, or more relevantly, even if it
were a Proxy, the underlying Window is not its target, we can even do
the following:
When the WindowProxy
On Tue, Jan 27, 2015 at 7:22 PM, Brendan Eich bren...@mozilla.org wrote:
Mark S. Miller wrote:
The reason why the intent is unwarranted is that the descriptor omits
configurable: rather than explicitly saying configurable: true. If the
owner object already has a configurable own property of
13 matches
Mail list logo
