Re: Non-constructible constructors and Arrays

On Thu, Sep 8, 2011 at 8:51 PM, Cameron McCormack <> 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.
> 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