LGTM from my side
https://codereview.chromium.org/15288011/diff/19001/test/mjsunit/harmony/iteration-semantics.js
File test/mjsunit/harmony/iteration-semantics.js (right):
https://codereview.chromium.org/15288011/diff/19001/test/mjsunit/harmony/iteration-semantics.js#newcode297
test/mjsunit/harmony/iteration-semantics.js:297: // Proxies and getters,
together at last.
On 2013/06/07 10:07:15, wingo wrote:
On 2013/06/07 09:29:52, rossberg wrote:
> Thanks. :) Sorry to pester, but can we also have a test where the
iterator
> is a proxy?
Done. However it doesn't work for generators, as iter.next() ends up
being
called with a proxy receiver, which fails as GeneratorNext() wants a
true
generator receiver.
This is orthogonal to for-of, however. What should happen for proxy
receivers?
Should GeneratorNext() unpack them?
Yeah, you just hit the core of the problem re proxies vs private state.
There won't be a real solution in ES6. Or ever. (This particular
instance might be addressed by the proposed 'invoke' trap, though.)
https://codereview.chromium.org/15288011/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
