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: Thu, 28 Jul 2011 07:27:48 -0700
Message-ID: <CABZUbM3V=-kYBKC9myACvR-+zCvSz9tgw6drJk-msOq+aabHhQ@mail.gmail.com>
To: Brendan Eich <brendan@mozilla.com>
Cc: Alex Russell <slightlyoff@google.com>, public-script-coord@w3.org, Cameron McCormack <cam@mcc.id.au>
On 7/27/11, Brendan Eich <brendan@mozilla.com> wrote:
> On Jul 27, 2011, at 10:32 PM, Garrett Smith wrote:
>> 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.
> Hi Garrett -- the issue isn't breaking existing behavior, it is extending it
> so you can "new" a NodeList. Is there a reason not to do this? Regularity in
> languages and APIs is better than irregular and seemingly arbitrary
> restrictions, all else equal.
What can a program do with `new NodeList()`?

Then also the problem with changing global Event, as I explained.

>>> 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"
> You mean the thread containing your message:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027668.html
> It's hard to tell what problems you mean, apart from browser differences
> that would be fixed by specifying better normative behavior, via WebIDL and
> relevant DOM and Web API specs. I mean, sure -- some browsers don't do the
> right thing with array generics on NodeList. This is not a reason to reject
> the idea of extending NodeList's spec (implementations to follow) so the
> generics work.
Well in this case, the proposal is technically speaking not to extend
NodeList but to re-design it so that it inherits from (extends) Array.
And fine, whatever, but what was brought up in that thread is the
questions of what do the methods do, e.g. given a nodeList that in a
document, what would aCollection.reverse() do, for example?
Received on Thursday, 28 July 2011 14:28:25 UTC

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