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: [email protected] [mailto:[email protected]
] 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
