Nov 18 notes

Brendan Eich brendan at
Mon Nov 22 19:21:19 PST 2010

On Nov 22, 2010, at 7:07 PM, Oliver Hunt wrote:

>> 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

Modifying the array prototype isn't relevant here (proxies on the prototype do not iterate, they enumerate -- see prior mail with js shell session excerpts). Not sure what you mean if not this -- adding methods to Array.protoype? PrototypeJS does this.

> 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.

I think you're arguing against something not proposed.

for (var v in values(a)) ...

requires no prototype monkeypatching. Somehow inserting a proxy with a handler having an iterate trap at the front of the Array.prototype chain won't work as noted already. If you thought I meant this:

for (var v in [1,2,3]) print(v);

printing 1 2 3, as I wrote in words cited at the top of this message "We can't satisfy this Pythonic expectation directly". Something like values would need to be called around the [1,2,3].

>  This is another reason i'm in favour of a different syntax - we could make it iterate values as people "expect".

I'm sure you are in favor of different syntax, but the argument you just made doesn't support that and it seems to have been based on a misunderstanding.

>>> 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.

Let's not argue by asserting who will be confused. I've already replied to Allen that the sword has two edges, one pointed away from skilled programmers. It's simply selective arguing to say only bad things happen in one direction. You can get cut; you can cut someone not intended. The issue is not whether for-in should be meta-programmable -- Proxy has an enumerate trap -- but how much.

> 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.

If we wanted to change Harmony's runtime semantics to be even less compatible than it is with no global object, we could wave a spec-wand and do that. Why don't we? The reasons won't go away.

The best we can do in any mostly-compatible spec edition is add new forms, whether syntax or API, and see if the cows beat new paths.

Dave's early message then observed that if all the developer cows happily use the new iteration form, the old one is basically dead. Reforming for (var v in [1,2,3]) at that very late date to iterate over values, assuming such a compatibility break is acceptable, simply won't matter by the premise: the cows moved to the new field.

>  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,

You can't override the iterate trap. Handlers are stratified and encapsulated. This is basic to the harmony:proxies design.

> 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.

Do you mean wrap a proxy with a different proxy having a different enumerate or iterate trap? Wrapping is not overriding. No mutation, different object identities.

I'm worried we are talking past each other now.

> 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.

Arrays are not proxies with handlers that contain traps. I think you are imagining unstratified __getattr__ hooks as in Python. But we aren't adding anything like that.



More information about the es-discuss mailing list