Re: Non-constructible constructors and Arrays

Hi Alex.

On 27/07/11 2:24 PM, Alex Russell wrote:
> The topic of WebIDL's last call just came up at the TC39 face-to-face,
> and one issue I've flagged but not posted here yet is the topic of
> non-constructible constructors. Section 4.3.5 contains an explicit
> example of a behavior that I'd like to see repaired:
>      // from:
>      var z = new NodeList(); // This would throw a TypeError, since no
>                                            // [Constructor] is declared.
> Browsers expose many of these (HTMLDivElement, etc.) and from the
> integration-with-ES perspective, they're mostly warts, not least of
> all because they co-exist with *actually* constructible constructors
> (Image, etc.).


> I'd like to propose that instead of blessing the non-constructible
> behavior that the lack of a [Constructor] *not* create a throwing
> function, but instead create a regular factory in the style of Image.

So this would eliminate the need for [Constructor], since all interface 
objects would be constructable?  Does this make sense?  (I agree it 
would be great for interface objects like HTMLDivElement and NodeList to 
be constructable.  (Well, maybe not NodeList, unless it gained 
functionality -- it would be useless without the ability to manually add 
Nodes into it.))

> On the topic of Arrays, I know it has come up before that there are
> DOM collection types, in particular NodeList, which should be Array
> subclass instances. I know that's outside the specifics of WebIDL, but
> I'd like to make sure that there's at least some accommodation in
> WebIDL for making this expressible until TC39 finishes the work of
> making it possible to directly subclass Array. Perhaps my reading has
> missed some infrastructure that might imply this or at least prevent
> it from being possible in an extension today?

The infrastructure does not exist in Web IDL still.  One kind of object 
*does* get the Array prototype object in its prototype chain, and that 
is "array platform objects" (formerly "array host objects"; name subject 
to improvement).  If you have:

   interface A {
     long[] f();

then the returned object will be an object with [[GetOwnProperty]] and 
[[DefineOwnProperty]] internal methods that cause it to look like a 
dense array of Number values, and whose [[Prototype]] is Array.prototype.

I realise what you want is for objects of particular interfaces -- which 
have their own methods -- to be able to inherit from Array.prototype. 
Now that we have the <| proposal, this (as well as the array platform 
object above) seems more feasible from a "let's implement the DOM in JS" 
perspective.  I think we should get agreement from the editors of DOM 
Core that that is what they want to do with NodeList and HTMLCollection. 
  If they do indeed want to do that (and I do agree it would be good), 
then someone can send in a LC comment on Web IDL requesting the ability 
to define these array-like interfaces.



Received on Thursday, 28 July 2011 06:07:51 UTC