Iteration in ES4

Jason Orendorff jason.orendorff at
Fri Apr 25 12:09:30 PDT 2008

Here are some more comments on iteration in ES4; still more to come.

=== for-each on Array objects ===

The planned behavior, as far as I can discern it, is like this:

  - Properties will be visited in the order they were added.
  - Enumerable properties of Array.prototype will be visited.  (This
    will hurt libraries that add extra Array methods there, like
    Prototype <>.  There are also
    more obscure cases.)
  - Non-numeric ("expando") properties will be visited.

I think users will find all these details astonishing and undesirable.
The first seems especially perverse.  No prior standard requires it.

The latter two are kind of implicitly specified in E4X.  A cost-benefit
analysis applies here.  The cost of following E4X is real, e.g. Web
pages that use Prototype can't use for-each on Arrays.  I don't see any
offsetting benefit.  Note that several ES4 classes will have custom
for-each behavior, so ES4's for-each generally won't behave the way it's
specified in E4X anyway.

=== "Type" suffix on structural type names ===

The proposal defines structural types named IteratorType, IterableType,
and ItemizableType.  I think they should be named Iterator, Iterable,
and Itemizable.  The proposal says the "Type" suffix is to help lead
people who aren't familiar with structural types away from a specific
mistake: trying to subclass IteratorType.  I doubt this will succeed.
People so inclined will reach for their subclassing hammer anyway.

And I think the funny names do a disservice to people trying to learn
the language.  Things that should be obvious to the point of tautology
("an Iterator object is an iterator") will need explanation ("an
IteratorType object is an iterator").  People coming from languages with
reflection or metaclassing will be extra confused ("is an IteratorType
object an iterator type?").  Please don't do this.

=== Generator.throw type parameter ===

The Generator class has a third type parameter, the type of exceptions
that can be thrown to it.  I can't think of a use case where this
doesn't feel like the Java "throws" clause, which ES4 otherwise rejects.
I think the throw method should accept any value, and the third type
parameter should be dropped.

=== Generator return-type annotations ===

The proposal doesn't specify how return-type annotations work on
generator-functions.  I think generator-functions should only accept a
return-type annotation that boils down to one of:

  *                       // (the default)
  Iterator.<X>            // I'm just an iterator
  Generator.<X, Y>        // I'm a coroutine

The run-time type of the generator-iterators produced by these functions
would be, respectively:

  Generator.<*, *>
  Generator.<X, void>   // I'm just an iterator, don't send() me data
  Generator.<X, Y>      // I'm a coroutine, send() me Ys


More information about the Es4-discuss mailing list