2009/12/8 Brendan Eich <[email protected]>: > On Dec 8, 2009, at 11:36 AM, Brendan Eich wrote: > >> Adding new syntax makes for-in a boat-anchor implementations lug around, >> in the best case. But realistically it will be years before developers can >> count on the new loop construct. And as support comes online, developers >> will have to choose which to use, and people learning JS will have to cope >> with two similar kinds of loops. Migration involves either a translator, or >> writing loops twice (a non-starter in practice), or using a source to source >> translator. > > Oops, I repeated the translator alternative when what I meant to say was > "people will stick with the old form, forever (for the life of that > content)." > > On the other hand if we evolve for-in, then new code can be written to > normalize the type of the index if necessary, and the normalization code can > go away later, or be tolerated if lightweight enough: > > for (let i in arraylike) { > i |= 0;
If this pattern catches on then we could optimize for it without changing the language. I think returning integers from for-in is a complete non-starter but I'm not volunteering to build a browser that does it just so I can check what breaks. > ... > } > > This is very cheap in some optimizing implementations if i is already a > number that happens to fit in a machine int. > > New syntax could be nice but for-in has its own gravitational pull, not just > due to precedent but due to similarity to Python and other languages. But > mainly it won't be usable for years and in the mean time, we'll have missed > a lower-cost migration path that evolves (or *reforms*, as in "recovers the > good Platonic form" ;-) for-in. > > /be > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
