Nov 18 notes
brendan at mozilla.com
Mon Nov 22 00:57:47 PST 2010
On Nov 22, 2010, at 12:49 AM, Peter van der Zee wrote:
> On Mon, Nov 22, 2010 at 8:37 AM, David Herman <dherman at mozilla.com> wrote:
> > for (var i : x) ... // must be new iteration
> > for (var i : T : x) ... // iteration again, but parsed how?
> > for (var i : T in x) ... // for-in with annotated var
> I'm beginning to feel more strongly again that overloading for-in, as opposed to introducing yet another syntactic variant of `for', is the right way to go.
> <thought experiment>
> Imagine we made Harmony backwards-incompatible in the following way: for-in loops would *only* work on iterable objects, and would dynamically fail on non-iterable objects. So if you wanted the legacy keys behavior, you would have to explicitly call a `keys' library function.
> </thought experiment>
> If we're gonna go invent new keywords why not use the obvious?
> iterate (var x in y) ...
Did you read Dave's previous post, or mine? "We" are not going to go invent some new overlong non-reserved word. "for" is the right word.
One might try retasking "do" but it's ambiguous: do-while loops do not require braces (K&R style favors them even for one-liners but it's just a convention).
Dave's point about getting people to use one universal quantifying loop structure is good. If that loop syntax is not for-in, it will have to be something new that works even when there is no iterate trapping proxy. But that will just be a suckier version of the universal (enumerating if not custom-iterating) for-in from JS1.7.
So what good are we really doing by forking for-in into bastard children (the one we have, definitely a bastard -- I should know! :-/) and a new one with red hair?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss