Re: Non-constructible constructors and Arrays

On Wed, Jul 27, 2011 at 2:24 PM, Alex Russell <slightlyoff@google.com> 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.

As has been pointed out by others, as things stand, being able to
create a new NodeList is utterly useless since there's no API to add
nodes to it anyway.

We could add an API which lets you add nodes to a NodeList, but what
would that do to NodeLists returned for document.forms or
element.getElementsByTagName?

Additionally, even if we add such API, why would you want to create a
NodeList rather than simply using an Array?

> 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, being able to construct HTMLDivElements is something that I think
is generally agreed is a good idea.

Someone mentioned that defining the ownerDocument would be a problem.
This can be trivially dealt with using just prose. There are several
APIs that does similar things, for example the XMLHttpRequest
constructor (which finds an owning Window), and Image/Option (which
finds a ownerDocument).

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

What would it do for things like HTMLMediaElement, Window, Node or
IDBObjectStore?

I most certainly agree that we should use constructors much more than
we have so far, but it doesn't seem possible to sanely create all
types of interfaces.

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

As I asked above, what would the mutating functions do to "live"
NodeList? And IMHO only APIs that want to return "live" objects should
return NodeLists. Others should simply return arrays.

/ Jonas

Received on Friday, 29 July 2011 00:05:53 UTC