Re: Non-constructible constructors and Arrays

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.  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.;r2=1.392;f=h

Could you indicate whether these two responses is satisfactory for the 
disposition of comments document?



Received on Friday, 9 September 2011 03:52:13 UTC