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 <[email protected]> wrote: > > > > On Sun, Dec 2, 2012 at 12:58 AM, Brendan Eich <[email protected]> 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 >>> [email protected] >>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >>> >> ______________________________**_________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >> > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
