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.
Ah, I get it -- indeed such deviations were one of the reasons for creating public-script-coord. SO I get it but I didn't lul. :-| > 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. We need to get this right in the future. It's a tricky issue. But even now I would say that if there's no observable difference, there is no problem. Allen should weigh in. /be > > I apologize again for my in-jest comment. > > Yehuda Katz > (ph) 718.877.1325 > > > On Mon, Nov 14, 2011 at 3:23 PM, Brendan Eich <bren...@mozilla.org> wrote: > 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 >> >> > >
