array like objects

[Brendan Eich]

Ok, let's think about a new loop construct.

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.

This all costs. It seems to me that the possibility of breakage under  
opt-in versioning is not worse than the costs listed above. But again,  
I welcome *real-world* examples (your example indicts polymorphic + as  
much as string-ifying for-in, but no one is proposing a new "concat"  
operator :-P)

Opt-in versioning will introduce new keywords including let and  
possibly yield, which constitute breaking changes. We know this from  
reality-based testing (Firefox 2 betas, JS1.7). While we haven't tried  
leaving for-in-iterated indexes as numbers in years (we used to, since  
ES1 made the change but Netscape's implementation did not for a  
while), I suspect the breaking-ness is less than the new-keywords- 
under-opt-in issue. But we are introducing new keywords, they're  
reserved in ES5 strict.

So I'll poke around with Google codesearch a bit later today.

/be

On Dec 8, 2009, at 11:18 AM, Allen Wirfs-Brock wrote:

> -----Original Message-----
> From: es-discuss-bounces at mozilla.org [mailto:es-discuss-bounces at mozilla.org 
> ] On Behalf Of Brendan Eich
> ...
>> If anyone knows of real-world code that would be broken by the type  
>> of
> the for-in loop variable not always being string, I'm all ears.
>
>> /be
>
> I don't have a real world example or a compelling use case for the  
> following, but it seems like it might (possibly inadvertently) occur  
> on the web:
>
> One place it makes a difference is if the + operator is used with  
> the induction variable:
>
> var a=[0,2,1];
> var b=[];
> for (var i in a) b[i+1] = a[i];
>
> In ES3/5, b will end up with properties named '01', '11', '21' and  
> length=22. Note that '01' is not an "array index" because of the  
> leading '0'.
> If for-in was changed so that i has numeric values for array index  
> property names then b would end up with property names '1','2','3',  
> and length=4.
>
> The changed behavior is probably(??) what would be intended by  
> somebody who did this, but changing it might still break apps that  
> are currently perceived to be working.
>
> My personal feeling is that rather than trying to "fix" various  
> things about for-in (including pinning down enumeration order) it  
> would be better to introduce a new more carefully defined  
> enumeration statement(s) (for keys/for values??) and leave for-in  
> alone.
>
> Allen