Array iterator questions

Brandon Benvie brandon at brandonbenvie.com
Sat Dec 1 22:20:38 PST 2012


When you say polymorphic dispatch with regards to
items(entries)/keys/values, you're saying the caller helps determine which
is used? This would make sense and resolve issues I've had. The generic
array iterator really helps to put a fine point on the limitations of using
any single default iteration type, as none are universally appropriate.
Some callers derive value from `[index, value]` but many just want `value`.


On Sun, Dec 2, 2012 at 1:03 AM, Rick Waldron <waldron.rick at gmail.com> wrote:

>
>
>
> On Sun, Dec 2, 2012 at 12:58 AM, Brendan Eich <brendan at mozilla.org> wrote:
>
>> Jason Orendorff wrote:
>>
>>> 1. The current draft spec has Array.prototype.@@iterator() behaving
>>> like .values(), so:
>>>
>>>     for (x of ["a"])
>>>         print(x);
>>>
>>> would print the pair ["0", "a"].
>>>
>>> The proposal had Array iterators producing values only by default. Why
>>> the change?
>>>
>>
>> This came up two days ago at the TC39 meeting. It's a drafting error.
>>
>>
>>  (It seems like it could be a typo, or it could be motivated by a desire
>>> for consistency across all collections. If the latter, Map should change,
>>> not Array.)
>>>
>>
>> There is some desire, which motivated Allen's
>> Array.prototype.{keys,values,**items} additions in the latest draft, to
>> have self-polymorphic method dispatch for implementing {keys,values,items}.
>>
>> This led to a discussion that concluded by separating the method naming
>> scheme and standard troika (and Andreas Rossberg proposed entries not
>> items, which everyone thought better), from the generic object-reflection
>> function troika that return iterators for property keys, values, and [key,
>> value] pairs. We argued about whether the two name-troikas should match,
>> and I think ended up allowing for this.
>>
>> Dave had a suggestion for adding a bit of "dict" veneer to the generic
>> functions in a standard module, but I'll let him 'splain that.
>
>
> I was mid-write up for this, but Brendan covered it more succinctly (thank
> you). I'll just add that the discussion, including resolution and consensus
> will be published on Monday along with all three days of meeting notes. I
> plan to file all of the resolutions as tickets on
> https://bugs.ecmascript.org/ tomorrow, so I suspect that Allen will have
> all of the changes in the next revision (barring unforeseen specification
> related issues).
>
> Rick
>
>
>
>>
>>
>>  2. According to 15.4.6.2.2, the iterators produced by
>>> Array.prototype.keys and .items will expose the index values as strings.
>>> Why strings? Don't numbers make more sense?
>>>
>>
>> Agreed these should not coerce to string.
>>
>> /be
>>
>>
>>> -j
>>>
>>> ______________________________**_________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>>
>> ______________________________**_________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>
>
>
> _______________________________________________
> 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/20121202/2c6225aa/attachment.html>


More information about the es-discuss mailing list