I've looked at your fiddle. The following assignment in line 5:
Symbol.iterator = Symbol('Symbol.iterator')
should fail (silently if you are not in strict mode), because the "iterator"
property of the Symbol object is not writable.
Therefore, in the rest of the fiddle, `Symbol.iterator` should refer to the
original @@iterator symbol, not to the replaced one.
(Your fiddle is a good illustration of why one should always run code in strict
mode.)
But to answer to the specific question: the spec always uses the original
@@iterator symbol, not the current value of `Symbol.iterator`.
—Claude
> Le 6 févr. 2015 à 10:19, Jordan Harband <[email protected]> a écrit :
>
> Should a JS engine retain a reference to the original value of well-known
> symbols (like Symbol.iterator), or should steps that use
> well-known-Symbol-valued properties (like for..of iteration) always do a
> dynamic lookup on that value?
>
> http://jsfiddle.net/hzzo10dm/2/ <http://jsfiddle.net/hzzo10dm/2/> is a proof
> of concept that demonstrates in Chrome 40 that by replacing Symbol.iterator
> with another symbol, I can create some weird behavior.
>
> What is specified to happen to built-in and custom iterables if I do
> `Symbol.iterator = Symbol()`?
>
> What I would expect is that either:
> - the original value of Symbol.iterator would forever be the only value in
> a realm that could be used to provide an iterator
> - or, that whatever the current value of Symbol.iterator, at that moment
> that would be the only way to retrieve an iterator on an object, thus
> overwriting Symbol.iterator should break all iteration.
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
