ES4 draft: enumerability

Brendan Eich brendan at mozilla.org
Tue Apr 22 16:50:03 PDT 2008


On Apr 22, 2008, at 2:06 PM, Jason Orendorff wrote:

> On 2008/4/10, Lars Hansen <lhansen at adobe.com> wrote:
>> Here's the first draft explaining how enumeration works in ES4.
>
> * It's unclear which parts of this, if any, are intended to be
>   normative.
>
> * Are the terms "enumeration", "iteration", and "itemization" defined
>   somewhere?


They are defined in http://wiki.ecmascript.org/doku.php? 
id=proposals:iterators_and_generators, at least.


>   Even if they are, I can't stop reading the first two as
>   synonyms, so I'd welcome a change in terminology.  Perhaps "for-in
>   iteration" for "enumeration", and "for-each-in iteration" for
>   "itemization"?


Those are mouthfuls. After some up-front definition, would not the  
shorter terms of art start to sink into your subconscious? They did  
in mine, but probably that's because enumeration is such a beast in  
JS, and iteration a la Python so much less full of baggage (unless  
the iterator author wants baggage). Also, Pythonic keys/values/items  
naming is short and sweet.


>   Renaming "GET" and "DEFAULT_GET" to something like
>   "FOR_ITERATOR" and "DEFAULT_FOR_ITERATOR" would leave room for
>   "FOR_EACH_ITERATOR" and "DEFAULT_FOR_EACH_ITERATOR".


See DEFAULT_GET_VALUES and DEFAULT_GET_ITEMS in the proposal.


> * The iterator proposal specifies additional special behavior when the
>   iterator "IT" is a generator-iterator.  Intentionally omitted here?


Do you mean it.close() automation? See also http:// 
bugs.ecmascript.org/ticket/47.


> * Is a more general introspection facility planned?  If so, I hope
>   DEFAULT_GET can be defined in terms of that and the Enumerator class
>   can be dropped.


Something has to specify enumeration, and we prefer self-hosting to  
prose for library code. Why is Enumerator objectionable?


> * The design of Enumerator doesn't make sense to me, especially that
>   it's a parameterized class.  What's the design goal here?


This is going to sound too technical and it immediately raises  
another question, but it's not arbitrary, and I'll answer the further  
question too:

To satisfy iterator::IteratorType.<T> while implementing deep and  
shallow enumeration (a la ES1-3 for (i in o) loop) and itemization  
(E4X's for each (v in o) loop).

Ok (you ask), why satisfy that generic structural type? Because  
that's the return type for the one iteration protocol hook,  
iterator::get, which ES4 checks to allow custom and superior  
iteration under the common, desired, and well-known for-in syntax.

Alternatives adding different syntax lose for not being Pythonic  
(ignore mandatory parens) and adding more special forms. Really,  
enumeration is a one-size-does-not-fit-all default that we want to  
keep for compatibility, but allow objects and classes to customize.  
Just like in Python (if you squint with those beer^H^H^H^HJS-colored  
glasses ;-).


>   To expose "get obj's public, enumerable properties, just like ES3
>   for-in", a static method suffices:
>
>     Object.getEnumerableProperties(obj: Object!): Iterable.<string>


Not quite. See the discussion at the top of the proposal.

* Something has to filter property identifiers deleted after  
enumeration or itemization starts but before those ids are visited in  
the snapshot.

* Something has to implement shadowing for deep properties (those  
found in a prototype object but having the same identifier as a  
property in the directly referenced object or a nearer object along  
its prototype chain).

These two, plus conversion of indexes to string type, are the hairy  
aspects of enumeration that we wish to implement under a uniform  
iteration protocol.

Also, Iterable.<string> must mean IterableType.<string>, as there's  
no type named Iterable in the proposal at least (did it get renamed?  
Checking... no, still IterableType).


>   If the goal is to expose a general API for getting various slices of
>   an object's set of property names,


... while also matching IteratorType.


> a static method still suffices:


A static method does not suffice for the "matching IteratorType"  
requirement.

IOW, the for-in construct (whether loop statement or comprehension,  
with or without 'each') is layered on a general iteration protocol  
hook a la Python's __iter__. But that hook is a typed function, and  
the return value is of type IteratorType.<T>.

/be



More information about the Es4-discuss mailing list