Re: What type should .findAll return

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.

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 <brendan@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.rick@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
>>
>>
>>
>
>