On Aug 1, 2010, at 10:55 AM, Kevin Curtis wrote:
> for (k in lst) { ... } // key
>
> for (v, in lst) { ... } // value - trailing comma
>
> for (v,k in lst) { ...} // value, key
We already have destructuring, which looks similar but with less ambiguity or
"lightness" (square or curly brackets, helpful to avoid typos and misreadings
by code reviewers).
Typically key comes before value when destructuring "items" (see Python and
other languages).
> And/Or using some symbol to indicate an iterator:
> for ([k,v] in @lst) {...} // with destructuring
> //@ = sugar for the method call to return the iterator.
> let it = @lst;
And if the @ operand is not a proxy with an iterate trap in its handler?
If the answer is to throw an error for want of an iterable, then some
(allegedly, see shallowCopy) generic code will work well, while other would-be
generic code will not.
Adding a way to opt into iteration instead of enumeration only helps if
enumeration is "right" -- but enumeration is broken in several ways, so the
long-term trade-offs are not so clearly in favor of keeping it under-specified
yet sacrosanct.
There are three parties (at least) involved in the evolving system: the for-in
loop author; JS hackers who might pass in any native, host, and proxy object;
and Ecma TC39 / the browser vendors and other JS implementors.
1. The for-in loop author may know exactly what objects could ever be on the
right of 'in', but let's assume not. The really challenging case is where the
loop is in a reusable function taking the object as a parameter. Such an author
has a hard time defending against host objects even today, never mind against
proxies tomorrow. Again, this applies to . and [] as well as for-in -- all can
give unusual answers down the road, although competition should (knock on wood)
keep the insane objects from proliferating.
2. The JS hackers who might pass in unexpected objects may not simply err or do
evil. Often they make clever use of the for-in-based library function, and
would like to smooth other any differences between implementations in how
for-in works. These users want more meta-programmability.
3. The TC39 committee can try to bikeshed syntax for new fixed points of
semantics, but as I've written, we are the least likely to get it right and
make it stick.
Which of the three parties is most likely to provide the right object for a
given for-in-based library function? My money is on party #2, the JS hackers at
large and in the future.
BTW @foo is already in use in ECMA-357 (E4X).
> How much leeway is there for adding new keywords?
We can add new keywords, especially contextual ones (although not in verbose
ways that users will hate). It is hard to prove new reserved identifiers won't
impose an oversized migration tax compared to the alleged benefit.
No one wants to add if there's a good way not to add (e.g., via a module or
other library API) that has as good or better usability than a keyword. Hence
our rejection of 'each' in favor of library (module) based standard iterators.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
