On Nov 22, 2010, at 2:08 AM, Tom Van Cutsem wrote: > 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.
You're not saving the addition of a looping construct, in making for-in behave differently depending on what is on the right hand side of 'in' you're merely adding an additional looping that is not syntactically observable. > - 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. And all existing standards compliant code can no longer rely on for in doing what it has done for years. Suddently for in _behaviour_ may change based on the prototype chain. > - 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). My understanding was that proxies would have a trap to allow them to generate an array of strings to be used. > > 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. I do not expect the behaviour of for(in) to change from harmony to non-harmony code. Ignoring all other concerns it would mean the behaviour of objects passed from a harmony context to a non-harmony context would be unexpected. I'm kind of frustrated that after discussing all this last week, and apparently getting to some kind of consensus, we've more or less instantly gone back to what we had at the beginning of the meeting, where for(in) gets magically overloaded and a developer has some magical way to understand what a given for(in) loop is going to do. If this was going to be the outcome why did we even spend time discussing this? --Oliver _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
