On Nov 14, 2011, at 3:13 PM, Yehuda Katz wrote: > It seems as though the spec intends to disallow host objects (i.e. DOM) from > fully acting like an Array, which is clearly the intent here. Perhaps this is > a time for "willful disobedience" and a correction in ES6?
Calm down -- this confrontational style is unjustified. The spec cannot deal in non-observables. DOM host objects in most implementations are full of methods, which really are native function objects. But it's always possible to implement a work-alike. So long as a host array follows the contract in every observable way, no problem. What's at issue is the abuse of internal methods defined only for spec-internal purposes as arbitrary "plugin APIs" by other specs. That's where negotiation and future-proofing are needed. /be > > Yehuda Katz > (ph) 718.877.1325 > > > On Mon, Nov 14, 2011 at 10:46 AM, Rick Waldron <waldron.r...@gmail.com> wrote: > [snip] > > ES5.1 clause 8.6.2 says: > > "The value of the [[Class]] internal property of a host object > > may be any String value except one of "Arguments", "Array",..." > > In other words, host object provides (such as a DOM implementation) are not > > allowed to define new kinds of objects whose [[Class]] is Array. > > It's fine to want to define a new kind of host object that is behaviorally > > very similar (but slight different) from instances of the built-in Array > > constructor. But characterizing such objects by saying they have > > [[Class]]=="Array" > > is a not meaningful from a ES5.1 specification perspective. > > I'm fine with any formulation, as long as it gives the correct behaviour in > cases like Array.prototype.concat and Array.isArray. > > ES 5.1 15.4.3.2 Array.isArray() > ... > 2. If the value of the [[Class]] internal property of arg is "Array", then > return true. > ... > > Considering Allen's previous comment, this is not going to be allowed. > > Rick > > > Do you have suggestions for what to write? > > / Jonas > >
