From: Allen Wirfs-Brock [mailto:[email protected]] Sent: Monday, November 14, 2011 6:12 PM > For right now, there are two ways you could quickly go that don't conflict > with ES5.1 at all: > > 1) you can specify that .findAll returns a plain vanilla ECMAScript Array > object. > 2) you can define a new kind of host object that is a close approximation of > a real ECMAScript Array object. Such an object could indirectly inherit from > Array.prototype, over-ride some inherited methods (such as concat and > filter), and define additional DOM related methods. However, its [[Class]] > may not be "Array" and anything in the ES spec that requires > [[Class]]==="Array" (such as Array.isArray) won't recognize it as an anything > special.
This might be my simplified view of things, but have we just circled back around to the two definitions that Cameron already has in WebIDL [1]? * 3.9.18 Sequences - sequence<T> are the corollary of #1 above (plain-old JS arrays) * 3.9.19 Arrays - T[] are the corollary of #2 above; array-like and even are participate in the Array.prototype chain. In section 4.2.20, the following note outlines the difference between the so-called platform array object and a vanilla JS array: "Note "Platform array objects differ from Array objects in the following ways: " - they are never sparse " - their elements are always data properties " - an ECMAScript-to-IDL value conversion is always performed when storing an element " - their internal [[Class]] property value is different " - their internal [[Extensible]] property value is always true Can we pick one of these as a starting point for .find()/.findAll()? For consistency with other DOM APIs, I personally see the platform array object as the way forward. [1] http://dev.w3.org/2006/webapi/WebIDL/#idl-sequence
