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

Re: Non-constructible constructors and Arrays

From: Alex Russell <slightlyoff@google.com>
Date: Thu, 28 Jul 2011 11:35:22 -0700
Message-ID: <CANr5HFUM9v=9ThO872y2r9PiBKDE0n4-ePJg=tYozBM9VRN+SA@mail.gmail.com>
To: Cameron McCormack <cam@mcc.id.au>
Cc: public-script-coord@w3.org, Brendan Eich <brendan@mozilla.com>
On Wed, Jul 27, 2011 at 11:07 PM, Cameron McCormack <cam@mcc.id.au> wrote:
> 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: http://www.w3.org/TR/2011/WD-WebIDL-20110712/#Constructor
>>     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.).
>
> Yes.
>
>> 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?

Yep!

It also opens the door for overdue fixes, like defining the arguments
these constructors should take, the document object that owns them,
and starting the discussion about how to give them shorter names = )

> Does this make sense?

Absolutely.

> (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.))

Why? NodeList "liveness" and ordering are artifacts of the APIs that
generate them, not the NodeList API AFAICT. The read-only nature of
the length property is busted, but not fatal. One could imagine that
push() could change it in the way that appendChild() does until DOM
Core gets repaired.

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

Prototypal delegation to Array.prototype is necessary but not
sufficient. Arrays currently include a magical length property which
we're looking to remove the magic from SRTL, and the question of
shadowing for integer-indexed properties remains (which is why there
are no Array subtypes in the base language today).

> I think we should get agreement from the editors of DOM Core
> that that is what they want to do with NodeList and HTMLCollection.

All I care about for the purposes of this discussion is that WebIDL
doesn't preclude it, because I think some of us on TC39 fully intend
to make Arrays truly sub-classable and I don't want to orphan the DOM
types when we get there.

Does DOM Core have editors right now?

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

OK.
Received on Thursday, 28 July 2011 18:36:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:04 UTC