Brendan Eich wrote:
It's never inconsistent to allow one thing and disallow another. The
particulars matter. This isn't "anything goes". Destructuring has a
bit of utility and a lot of regularity in for-in head position. The
initialiser from VariableDeclarationNoIn has neither specific utility
nor regularity with respect to for-in in AWK, Python, or any other
language with such a construct.
More to say, I sent too soon. Don't take this as more than it is: an
attempt to explore an alternative meaning of for-in combined with
certain destructuring patterns.
We have a request that seemed to receive popular support, to support
for own (k in o) ...;
This could compose with the following nicely, and it tries to pave the
CoffeeScript cowpath a bit (without taking CoffeeScript as normative or
overriding or anything like that).
We could make just-so meanings for destructuring in for-in, also
inspired by CoffeeScript (and JS1.7, which did this too while muddying
the waters by failing to separate iteration protocol into for-of):
for ([k, v] in o) ...;
Our current position is "use for-of and an items helper function":
import items from "@reflect"; // currently @iter; could be part of
standard prelude
for ([k, v] of items(o)) ...;
But I think detailing the design of ES6 must be allowed to entertain an
even easier-to-use extension to for-in.
If you want values not keys, then per the current proposal you use
for (v of values(o)) ...;
given the necessary values import, or inclusion in a standard prelude.
There's a hole vs. CoffeeScript: we do not want for-of on a plain Object
to iterate over enumerable property values. Arrays, yes, Objects, no --
no Object.prototype.@iterator. So no |for (v of o) ...| for o = {p:1,
q:2, r:3}.
Also no for each (v in o) as E4X (ECMA-357) promulgated. SpiderMonkey
and Rhino support it and probably will have to carry it, but such "each"
does not say its meaning (values not keys) clearly, and it doesn't
compose with "own" nicely.
But with destructuring for-in, you could write
for ([, v] in o) ...;
This is a bit ugly (holes never look pretty, even when they're useful).
Not sure what I think of this but I thought I'd throw it out here on
es-discuss. The reason I bring it up is twofold: 1) for own (k in o)
still needs to be discussed; 2) the for ([k, v] of items(o)) ...; tax is
a bit higher than I'd like.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
