W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2011

Re: What type should .findAll return

From: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Fri, 11 Nov 2011 13:22:18 -0800
Cc: public-script-coord@w3.org, public-webapps <public-webapps@w3.org>
Message-Id: <70A18B50-69AE-43B3-8F27-25E7A1315B04@wirfs-brock.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
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.

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

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?


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:04 UTC