array like objects

Erik Corry erik.corry at
Tue Dec 8 11:51:00 PST 2009

2009/12/8 Brendan Eich <brendan at>:
> 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
> es-discuss at

More information about the es-discuss mailing list