Standard @iter module unfriendly to collection builders

Brendan Eich brendan at mozilla.com
Mon Nov 14 11:57:45 PST 2011


On Nov 14, 2011, at 9:07 AM, Allen Wirfs-Brock wrote:

> On Nov 12, 2011, at 12:05 PM, Brendan Eich wrote:
> 
>> On Nov 12, 2011, at 11:26 AM, Allen Wirfs-Brock wrote:
>> 
>>> The Iterators proposal includes the definition (http://wiki.ecmascript.org/doku.php?id=harmony:iterators#standard_api ) of functions that are intended to support various common iteration patterns.
>>> 
>>> For example,   
>>> 
>>>   for ((k of keys(x)) { ...}
>>>   for (v of values(x)) { ...}
>>>   for ([k,v] of items(x)) {...}
>>>   for (k of allKeys(x)) { ...}
>>>   for (k of allValues(x)) { ...}
>>>   for (i of allItems(x)) { ...}
>>> 
>>> The use of these functions seems to be pretty much an essential part of the intended use of the for-of statement.
>> 
>> The prior question is what, if anything,
>> 
>>   for (x of y) ... // and [x for x of y], etc.
>> 
>> means.
>> 
>> Should it throw if there's no @iterator private-named property in y *and* y is not a Proxy with an iterate trap? That is our current thinking. It may not be reflected well in the wiki.
> 
> Another possibility would be to build in default @iterator methods on Object.prototype and Array.prototype.  I'd probably make the object implementation be an items for enumerable properties and the array implementation iterate the values of 0..length-1 .

Not a bad set of defaults if Object.prototype was not a prototype of Array.prototype, and I was inclined the same way once upon a time.

But then Jason (cc'ed) made a good argument (which I resisted fiercely at first because of the obvious utility of the defaults) that doing so in ES.next means anyone customizing collection iteration later will break generic code that wants only items, or only values.

Really, JS is different from Python in this way: Array and Object are more like list+object and dict+object hybrids, and in Python class instances (objects) throw without a custom __iter__. They do not act like lists or dicts.

Generic code will suffer, and type confusion bugs will tend to be more common ceteris paribus, if we do what you suggest.

I tried patching the defaults to be value-only iteration. That still is future-hostile to evolving collection @iterator settings, but it's better.


> Yes,  suspect that people defining collections would routinely want to over-ride @iterator.  However, the defaults probably do establish some expectations.  Particularly if we aren't providing many (any?) built-in collections  that might establish other expectations.

We might need to do some work there, with the community and prototype implementations.

/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111114/55568da7/attachment.html>


More information about the es-discuss mailing list