On Nov 23, 2010, at 12:11 AM, Maciej Stachowiak wrote:
> One possibility is to add a space as apparently a few other languages do:
>
> for each (var i in x)
>
> Should be unambiguously parsable and easy to understand.
This is what ECMA-357, E4X, does, and it indeed iterates values not keys. The
obvious criticism is that nothing except (dubious) history says for-in == keys
while for-each-in == values. Other symmetries break down:
for (i in o) assert(i in o)
lacks this parallel construct:
for each (v in o) assert(o[what-was-v's-name-again?] === v)
JS1.7 allowed key-value destructuring
for ([k, v] in o) assert(o[k] === v) // assume idemptotent has/get
but this broke a different symmetry:
for ([s, v, o] in tripledb) ...
which wants other destructuring patterns to destructure the value returned by
the iterator. Making the two-element-array destructuring pattern mean key-value
destructuring frustrates people who want to iterate over a pairdb. So we fixed
this in JS1.8, and dherman's iterator proposal has
for (k in keys(o)) ...
for (v in values(o)) ...
for ([k, v] in properties(o)) ...
EIBTI once again.
>> Anyway, the bikeshed is secondary. We need to agree on what
>> meta-programmable for-in means with the enumerate trap (specified by the
>> wiki pages on harmony:proxies), how that changes with the optional iterate
>> trap (strawman:iterators), and when it might matter (for all for-in loops,
>> or only those in Harmony code?).
>
> Fair enough. Another important question is whether for..in should continue to
> guarantee that all values enumerated would be strings. Preserving that
> guarantee clearly makes for..in useless for the strawman:iterators purpose,
Not quite, as Andreas already argued and (I see, reading ahead) reiterates with
dherman adding emphasis.
Stringifying is not good for iterating arbitrary values, in particular property
values or key-value pairs, of course. But if you insist (I don't) that for-in
always stringify, forever, there are still lazy use-cases for the proposed
iterate trap.
> but not for the harmony:proxies enumeration trap (and thus iterators would
> need new syntax to be usable). Breaking the guarantee may cause problems for
> existing code. Breaking the guarantee only in Harmony mode creates additional
> migration tax. Thus, iterators create a potential motive for new syntax that
> the proxy enumeration trap does not.
We're going in circles. Clearly, we could add new syntax. It's also conceivable
that we could extend for-in. Trade-offs abound and data on usability hazards is
absent in our experience (JS1.7 and up).
> Given this, it is useful to identify candidate syntax that doesn't have
> perceived showstopper problems, so that we can evaluate the tradeoffs among
> the three prongs of the trilemma.
It's a problem if showstopper criteria are not shared in a committee. Then
anyone can stop the show based on divergent principles or unarticulated beliefs.
It therefore seems more important to achieve consensus on principles, and less
important to force new syntax as a compromise that may be founded on bad
committee game theory.
> (As an even more concrete previously mentioned example, a new syntax allows
> sane defaults for arrays without breaking compatibility for the existing
> construct.)
Mozilla-specific JS hackers do use
for each (v in a) ...
to iterate values in an array |a|. This is better than
for (i in a) { v = a[i]; ... }
but it's not so much better that TC39 members are happy to adopt for-each-in
from ECMA-357. Maybe we will, in the end. It is overlong and "each" is
redundant or ambiguous (take your pick), but at this point it beats the rushed
for-: ugliness of last week.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
