Day 2 meeting notes

Brendan Eich brendan at
Sun Aug 1 11:29:58 PDT 2010

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.


More information about the es-discuss mailing list