My arguments in favor of keeping the existing "for-in" syntax and making it meta-programmable:
- Simplicity. Don't underestimate the complexity creep of introducing a new looping construct. Many small changes add up quickly. Especially for novices, having two looping constructs that are so similar will be terribly confusing. - Keeping the existing syntax means that the tons of JS code already out there can instantly become client-code to iterators. As Brendan noted: you can use iterators to generate a stream of keys (strings) without confusing clients. - Client code to proxies that emulate objects with lots of properties can continue to use for-in. It just feels wrong that client code should change because of pure implementation details of an object (i.e. whether it eagerly or lazily generates its keys). Of course, if an object changes its behavior from iterating keys to iterating values, this breaks clients and they should be modified to use "for (var k in keys(obj))". But I don't see how this differs from any other such changes made to an object. The important thing to note here is that turning an object into an iterator requires explicit action by the programmer. If iterators were implemented ala Python using a magical "__iterate__" hook, then I'd complain because Harmony code could silently turn normal objects into iterators. But there's no such risk with this proposal. 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. Cheers, Tom 2010/11/22 Brendan Eich <bren...@mozilla.com> > On Nov 22, 2010, at 12:49 AM, Peter van der Zee wrote: > > On Mon, Nov 22, 2010 at 8:37 AM, David Herman <dher...@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 >> >> Bummer! >> >> 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? > > /be > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
