Standard @iter module unfriendly to collection builders

[Brendan Eich]

On Nov 13, 2011, at 10:17 AM, Erik Arvidsson wrote:

> Another thing to consider is whether these functions belong in an iter module or in a reflect module? I'm leaning towards the letter.
> 

Does it matter, apart from the name?

I'd rather have more and more precisely defined modules than one reflect dumping ground. JS has built-in reflection, from day 1, arguably overloaded with base-level operations but part of the package deal. We won't be factoring all such unstratified reflection out.

The "@iter" name is short and Python-inspired, it should match for-of loops, comprehensions, and generators. It could grow too large, but it wouldn't be larger than "@reflect".

If we end up with a standard prelude, some of these helpers could be imported by it.

/be

> On Nov 12, 2011 12:05 PM, "Brendan Eich" <brendan at mozilla.com> 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.
> 
> The alternative is to iterate over property values of an object denoted y that has no unstratified @iterator or stratified handler iterate trap. But that is hostile to collections and your [] proposal.
> 
> OTOH I see no problem for collection writers if we make for-of throw on untrapped objects. Collection authors would bind @iterator, @elementGet, and @elementSet. Life would be grand. Right?
> 
> /be
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111113/7ca1ac6a/attachment-0001.html>