> The most frequent (in my hearing) unsatisfied expectation of users of for-in > is not that it is a second form after the C-based for(;;) -- there's no > mention of for(;;). Rather, it is that for (v in [1,2,3]) fails to iterate > 1,2,3, instead enumerating "0","1","2". > > We can't satisfy this Pythonic expectation directly, but with > meta-programmable for-in, users and library authors can help themselves, > using keys, values, and other iterator factory functions.
Library authors can't really do this without providing their own array classes, modifying the array prototype would be too dangerous in a web environment to be done by a library as it would not work with other code that may expect current for-in behaviour, same applies to NodeList's, etc in the DOM. This is another reason i'm in favour of a different syntax - we could make it iterate values as people "expect". >> Further complicating it feels like it would be a pedagogical nightmare. > > I think this is exaggerated -- there's really no relation to for(;;), and the > first-year students move up and on. > > The nightmare of unprogrammable for-in, if I may use that word, is both the > non-interoperable mess of for-in today in ES3-ES5-level browsers, plus the > enumerate trap of tomorrow -- never mind an iterate trap. But most > programmers do not need to know about proxies. I am most concerned about this making for-in much more complicated; Yes python has had meta-programmable objects forever (give or take a few years :D) which shows people can understand the behaviour, but the default behaviour exhibited in python is different, and more in line with what people expect. By changing for(in) behaviour in harmony you're trying to give python like meta-programming but with less than ideal defaults for new developers, and confusion for experienced developers. I think the other problem i have is that what people really seem to want is value enumeration of arrays (and array-likes), and by re-using the syntax you basically ensure that at the very least arrays (and other array-likes) will never get that behaviour by default. In addition to that it would be very dangerous for any library to override the iterate trap as libraries want to interact well with other libraries, and also provide a consistent development environment across multiple engines and versions. That leads me to expect that libraries would not override the enumerate trap. If we had a new syntax, in addition to allowing meta-programming from the get-go, we could also provide default enumerate traps for arrays, etc that is inline with what people expect. --Oliver _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
