Yes, we should have a new covenant that avoids adding stringized array
indexes for new APIs. New APIs need to turn down the arrays-are-objects
setting JS had from 1.0 (JS1 in 1995 had something even more
object-like: objects equated indexes to property names added in creation
order! See DOM forms/elements/links array-likes where elements can have
aliasing names depending on markup...).
/be
Rick Waldron wrote:
On Sun, Dec 2, 2012 at 2:47 PM, Allen Wirfs-Brock
<[email protected] <mailto:[email protected]>> wrote:
On Dec 1, 2012, at 8:14 AM, Jason Orendorff wrote:
snip
> 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?
>
It does that because array index keys are exposed as strings
everywhere else.
There is no specific definition (that I can find) of the keys
iterator for arrays in the wiki proposal. There is only the
general @iter.keys function which is defined in terms of for-in
and hence returns string property keys.
However, I don't have any objection to return integer keys in this
case.
+1
Users will take this for granted and assume the index value is going
to be a number since map, forEach, filter, every, some and reduce all
pass a number as the index argument and for-loops increment a number.
Rick
Allen
_______________________________________________
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
