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, 8 Sep 2011 23:45:35 -0700
Message-ID: <CANr5HFW1pfZBFBFVayiY=tokxx1RfbZ3fbAPuHHSjZsgFx75rg@mail.gmail.com>
To: Cameron McCormack <cam@mcc.id.au>
Cc: public-script-coord@w3.org, Brendan Eich <brendan@mozilla.com>
On Thu, Sep 8, 2011 at 8:51 PM, Cameron McCormack <cam@mcc.id.au> wrote:
> On 28/07/11 7:24 AM, Alex Russell wrote:
>>
>> 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'm not going to make this change, because I think it doesn't always make
> sense.  There are interfaces such as CharacterData that are never used as
> the most-derived interface that an object implements.

Wait, why shouldn't I be able to new-up a CharachterData item?

And in any case, if the *default* is to want this, why not simply flip
things the other way, add a new noconstructor attribute or similar?

>  I think it should be
> up to individual specifications to decide whether a particular interface
> should be constructable and if so what it's behaviour should be.
>  Specifications need to define the particular behaviour of the constructor
> anyway.  We should just encourage specifications to make use of constructors
> as much as makes sense.
>
>> 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?
>
> I've added an extended attribute [ArrayClass] that can be placed on an
> interface (that doesn't inherit from another).  This causes its interface
> prototype object's [[Prototype]] to be Array.prototype rather than
> Object.prototype.  The remaining mechanics of getting the object to work
> properly with the inherited Array methods (properties for length and array
> elements) is left to the API designer.
>
> http://dev.w3.org/cvsweb/2006/webapi/WebIDL/Overview.html.diff?r1=1.391;r2=1.392;f=h
>
> Could you indicate whether these two responses is satisfactory for the
> disposition of comments document?
>
> Thanks,
>
> Cameron
>
Received on Friday, 9 September 2011 06:46:42 UTC

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