Re: What type should .findAll return

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