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

Re: Non-constructible constructors and Arrays

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Wed, 27 Jul 2011 22:32:08 -0700
Message-ID: <CABZUbM1NKLyHp4ian6ryjhaS=DddkvYf6CLWG1akZDAEjtDXnw@mail.gmail.com>
To: Alex Russell <slightlyoff@google.com>
Cc: public-script-coord@w3.org, Brendan Eich <brendan@mozilla.com>, Cameron McCormack <cam@mcc.id.au>
On 7/27/11, 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.
Existing browser behavior seems fine by me.

> 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.).
Sure, Image and Option are constructors and Event and HTMLCollection
aren't. I don't see that as a problem.

However, when it comes to the spec conversion of the existing
interface objects to become callable or constructible, then there is a
problem, because now you have global `Event` interface, as an object,
then the new `Event` interface as a function, and a Mootools `Event`
function. That it puts scripts in a position of having to not only
determine but discriminate and handle difference between the three
different `Event` objects.

Don't change existing objects' behavior.

> 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.
I'd like to propose the exact opposite, for reasons given.

> 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.
The problems with that were quickly uncovered on:
"[whatwg] Adding ECMAScript 5 array extras to HTMLCollection"

Not trying to be controversial, just AISI.
Received on Thursday, 28 July 2011 05:32:36 UTC

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