Re: What type should .findAll return

Yehuda Katz
(ph) 718.877.1325


On Mon, Nov 14, 2011 at 3:49 PM, Brendan Eich <brendan@mozilla.org> wrote:

> 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.
>

One observable difference between this object and an Array (at least under
Jonas' proposal) would be that:

Object.getPrototypeOf(Object.getPrototypeOf(arrayOfNodes)) would be the
inserted DOM list prototype, while
Object.getPrototypeOf(Object.getPrototypeOf(regularArray)) would be
Object.prototype

It would be possible to mask this behavior, but masking it and also making
it possible to extend the DOM list prototype would be weird, no?


> /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 <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
>>>
>>>
>>>
>>
>>
>
>