Re: Non-constructible constructors and Arrays

On Jul 31, 2011, at 4:50 PM, Cameron McCormack wrote:

> Here is a proposal (which I haven't thought deeply about yet): any interface that supports indexed properties and which does not inherit from another interface has Array.prototype as its prototype object's [[Prototype]] instead of Object.prototype.  Objects implementing these interfaces get the magic length property (or inherit the non-magical accessor property if that's what ES changes to have).  It is then incumbent on the API designer to define index setters/creators/deleters appropriately such that the mutating Array methods make sense.  Would this work?  Is there a problem with sparse Arrays at all?

This don't sound quite right to me.  There is nothing magical about Array.prototype.  It is just a collection of properties and an object does not actually have to inherit from it to support those exact same properties.

WebIDL already has the concept of objects that support multiple interfaces and the ECMAScript WebIDL binding defines how to merge those into a single prototype inheritance chain. That seems like the appropriate way to handle Array.prototype functionality.  Simply define an interface that specifies all the relevant Array methods by reference to the ECMAScript spec.  You can even break it into to separate read-only and mutable array interfaces if you wish.  Make interfaces with indexed properties inherit from that interface. (If you don't want the ECMAScript array interface(s) to show up for non-ECMAScript WebIDL specify this just for the ECMAScript binding).  Them the array methods should just "mix-in" using the already specified mechanism.

The "magic" length property is an orthogonal issue.  The generic Array.prototype methods don't depend upon it.  If you have DOM collections that you want to have that "magic" behavior you probably need to separately specify that.  However, it isn't obvious to me that you need to.

Allen

Received on Monday, 1 August 2011 18:00:12 UTC