No subject

Tue Oct 5 19:45:07 PDT 2010

distinct from the current for-in and probably the greater the syntactic 
distance from for-in the better.  Following these principles, here is a 
suggestion for a new enumeration statement that makes use of existing 
reserved words:

enum key with keys(x) {

enum val with values(x) {

enum  [key, val] with properties(x) {
    alert("x." + key + " = " + val);

Since this is a new form, it can impose new syntactic conventions.  For 
example, it always creates new bindings in the block that it iterates.  An 
explicit var or let keyword is not needed. Also "with" has much broader 
semantic implications than "in"

2) Whenever possible, less general pre-existing syntactic forms should be 
redefined to desugar into new more general forms.

ES1-5 for-in can be defined via desugaring to enum-with, for example:

//desugar:   for (var x in foo) {alert(foo[x])}
var x;
enum __x with __ES5forinEnumerator(x) {

3) Proxy traps should be defined based upon the new, more general semantics 
not legacy less general semantics.

Define the traps necessary to support enum-with and depend upon the 
desugaring to take care of legacy for-in.

4) Provide builtin-library alternatives for new statements that can be used 
without down-rev syntax errors:

Iterator.prototype.enumWith = function (func) {
    enum each with this {

properties(x).enumWith(function([key,val]){alert("x." + key + " = " + 

Leave it to library writers as to whether or not down-rev libraries are 
actually implemented.

-----Original Message----- 
From: Brendan Eich
Sent: Monday, November 22, 2010 12:48 PM
To: Oliver Hunt
Cc: es-discuss
Subject: Re: Nov 18 notes

On Nov 22, 2010, at 12:39 PM, Brendan Eich wrote:

> On Nov 22, 2010, at 12:09 PM, Oliver Hunt wrote:
>> How do library authors help?  They can't add value enumeration of 
>> anything as that will break any existing code that uses for(in) over any 
>> of their objects.
> As Tom pointed out (re-read his message :-|), they can make enumeration 
> work for large/lazy/infinite objects. No non-string non-keys required.

The important point here is that for-in won't choke old browsers. New 
library code in the near term (when Harmony and pre-Harmony impls are in the 
field), assuming we let for-in be metaprogrammed in Harmony, can 
object-detect and meta-program for-in, and client *and* library code can use 
for-in and it will fail soft or fall back by other means.

Not so if we add new syntax (for-: or anything old browsers will choke on).

es-discuss mailing list
es-discuss at 

More information about the es-discuss mailing list