On Nov 14, 2011, at 3:32 PM, Yehuda Katz wrote: > Sorry, > > I was making a joke (referencing 1.5.2 of the HTML5 spec), not intending to > be confrontational. > > The underlying issue here is just making it possible for Array.isArray to > return true for an Array of DOM nodes that is also enhanced with extra > features. Jonas had specifically said that he wanted isArray to work. Rick > then pointed out that the spec seems to disallow host objects from claiming > that their [[Class]] is Array, and that isArray specifically requires that > [[Class]] be Array.
Ultimate you have to decide what it is you are asking for. It been stated that you (DOM API designers) want this kind of object to be a real ECMAScript Array. But you also want to deviate from some aspects of what it currently means to be an a real ECMAScript array. A "real ECMAscript Array" has a specific [[Prototype]] value. It also has specific behaviors for methods like concat and filter and other specific distinguishing behavioral characteristics all of which are defined in the ES5.1 spec. If you change any of those for some object, it is something other than a real ECMAScript Array. Array.isArray was introduced into ES5 to provide an API for testing whether or not an object actually was a real ECMAScript Array as defined by section 15.4 of the ES5 spec. If Array.isArray starts answering true for objects that aren't described by 15.4 then it ls no longer useful for its intended purpose. The language in 8.6.2 limiting host object use of certain class values is to ensure that host objects can't define things that violate important invariant about the inner workings of ECMAScript. Nobody is saying that it isn't useful to define new objects (host or otherwise) that share some (but not all) of the characteristics of ECMAScript Arrays. However, such object's aren't just ECMAScript array as defined by 15.4 so don't expect Array.isArray to work for them. Perhaps other discriminators are needed but we will all need to decide which specific subset of Array characteristics we want to discriminate. TC39 recognizes that ES needs better support for defining collections, including variants of Array. This includes supporting both better collections defined in ES code and via "host objects" (in general, TC39 don't like designs that depend uopn a host object being able to do something that can't be done only using ES code). We have features to support better collection definition in advanced stages of design for "ES6". Some of these features might be accelerated into implementation ahead of the completion of "ES6". However, I'm not sure you would want to normatively specify a DOM feature that depended upon them. Maybe you could... 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. We can work together on something between these two extremes but the further away from them we go the more we get into the land of ES6 features and the problem of how to advance them into current engines. Allen
