Re: What type should .findAll return

Note that the only specialness of Array instances relates to what happens when you add new array elements or dynamically change the value of the "length" property.

If the array instance is immutable you can't do any of those things so its specialness essentially disappears.

So, if you want the objects to be an immutable, array-like object that inherits from array.prototype through an intermediate prototype there really is no problem.  A JS programmer could express this today in ES5:

var DOMFindResultProto = Object.create(Array.prototype);  //make it inherit from Object.prototype
DOMFondResultProto.someMethod = function O() { ...};
//other prototype methods
//...

function FindResultFactory(nodes) {
   var obj = Object.create(DOMFindResultProto);
   for (var i=0; i<nodes.length;++i) obj[i]=nodes[i];
   return Object.freeze(obj);
}


However, if you want the object to be mutable and to act like a real array, then it has to have the array specialness.  The specialness comes, not from the [[Class]] property but from its alternative definitions of [[DefineOwnProperty]] (see ES5.1 spec. 15.4.5.1).

In ES.next a JS programmer will be able to easily define such an object.  But for ES5 it takes special implementation level intervention.    Since this capability is going to ultimately be in ES.next I don't see why you couldn't do it now, assuming the the engine implementors are all willing to cooperate.

Basically, you would specify that the [[Prototype]] of the instances inherits from Array.prototype and that the instances use the [[DefineOwnProperty]] specification from ES5 section 15.4.5.1.

In either case, you would be specifying a new kind of ES "native object" rather than a "host object'.

BTW, I think that either the immutable or mutable approach would work.  However, since the collection is not "live" I don't see why you would really care whether or not a client mutated it.  If they want to process it by deleting elements after they are examined, so what?

Allen






On Nov 11, 2011, at 12:20 PM, Boris Zbarsky wrote:

> On 11/11/11 10:05 PM, Jonas Sicking wrote:
>> In other words, the returned object is exactly what you'd get if you did:
>> 
>> a = new Array;
>> a.__proto__ = [some type].prototype;
>> [some type].prototype.__proto__ = Array.prototype;
> 
> For what it's worth, at least some JITs deoptimize |a| if you do that. We'd probably need to do something to make sure that _doesn't_ happen in this case, right?
> 
> -Boris
>

Received on Friday, 11 November 2011 21:23:03 UTC