I agree that implementing it as a data property would be rather painful. I
think
it's fine to do this as an accessor for the time being. We can try to lobby
for
making that legal in the spec, although I kind of doubt that will be
successful.
(If you ask me, arguments iterators should be removed from the spec
altogether.)
https://codereview.chromium.org/342453002/diff/1/test/mjsunit/harmony/arguments-iterator.js
File test/mjsunit/harmony/arguments-iterator.js (right):
https://codereview.chromium.org/342453002/diff/1/test/mjsunit/harmony/arguments-iterator.js#newcode39
test/mjsunit/harmony/arguments-iterator.js:39: assertIteratorResult(void
0, true, iterator.next());
Nit: no reason to use void 0 instead of undefined in tests.
https://codereview.chromium.org/342453002/diff/1/test/mjsunit/harmony/arguments-iterator.js#newcode120
test/mjsunit/harmony/arguments-iterator.js:120: function
TestIndirectValues4(a, b, c) {
It would be good to also test that
- changing an arguments slot is reflected in the iterator
- changing a sloppy arguments slot through an aliased parameter variable
is reflected in the iterator
- changing a parameter variable does not effect strict arguments
iteration
https://codereview.chromium.org/342453002/
--
--
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/d/optout.
