On Nov 23, 2010, at 11:12 AM, Brendan Eich wrote: >> 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.
The principle could be refined from Dave's restatement of Allen's (1a): 1a'. If existing syntax is given new semantics, it should extend the existing semantics conservatively. Otherwise, the new semantics should get new syntax. But "conservatively" needs defining. I think rather than try to nail down an abstract principle, we should look at the particular things in themselves. Tom's post did this: "I think that's a key point worth re-iterating: iterators and regular objects are sufficiently distinct so that there's no risk of automatically converting one into the other. There is only a risk to existing client-code if a Harmony programmer changes a normal object into an iterator. But at that point the programmer knows he's making a non-upwards-compatible change and clients should be changed accordingly. I don't see how the for-in case differs in this respect, fundamentally, from say, renaming a method." [https://mail.mozilla.org/pipermail/es-discuss/2010-November/012208.html] This is an argument about APIs. If an object exposed by an API, say returned from an API function, was a plain old object with keys to enumerate, but now (with Harmony implementations targeted) returns a proxy with an iterate trap, *and* the iterator returns non-strings non-keys (but key is ill-defined if not "string"), then client code *could* break. But this is an intentional API change. It is analogous to renaming a method, and plausibly, object detection if not renaming would be used to deal with downrev clients. What about unintended consequences? An accidental proxy leak from Harmony code to pre-Harmony code is possible. This is why I raised the idea of runtime semantics under Harmony opt-in being required to meta-program for-in. The same opt-in is required to remove the global object from the scope chain in favor of a lexical top frame. We can (and have!) argue about limits on migration taxation, implementor burdens, etc. But as ES5 strict changed runtime semantics, it seems Harmony will too (lexical scope). So it is not absolutely inconceivable, or even "obviously wrong", that for-in might become metaprogrammable based on its static code "in Harmony" property. >> (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. Lest anyone think I'm throwing in the towel -- I'm not. We need better principles and detailed arguments justifying them or we won't have lasting and sound consensus to do much of anything with the language. Proxies moved to harmony:proposals status because they were designed carefully, very well specified, and prototype implemented (and the prototyping was essential to completing the spec and getting the design right). On one point of contention in the July meeting, I urged TC39 to let the champions of the proposal (Mark and Tom), decide what to do. I'd like to continue this champion-decides approach. Committees are terrible at designing, specifying, and implementing. It would be much better if we had multiple Proxy implementations (one for v8 is on github, Tom noted recently: https://github.com/brickysam26/node-proxy), including the iterate trap as proposed, and then some early adopters using proxies and beating on the iteration protocol. At that point we would have more information on the usability issues. In the mean time, we can try to refine our principles based on concrete analysis. Just making abstract "never do X" rules won't cut it. /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
