Re: Non-constructible constructors and Arrays

On 7/28/11 11:35 AM, Alex Russell wrote:
> On Wed, Jul 27, 2011 at 11:07 PM, Cameron McCormack<>  wrote:
>> So this would eliminate the need for [Constructor], since all interface
>> objects would be constructable?
> Yep!

Don't you still need [Constructor] for declaring constructors that take 
arguments?  Image has multiple constructors, for example (though it uses 
NamedConstructor to declare them since the interface name is 
HTMLImageElement).  If creating a no-arg constructor is the default, 
then perhaps it is unnecessary to have both Constructor and 
NamedConstructor...  Remove Constructor and rename NamedConstructor to 
Constructor?   But there needs to be some syntax for declaring 
constructors with arguments.  Alex: you're not proposing to modify the 
idl syntax itself (rather than the extended attributes) are you?

And what about interfaces for which a no-arg constructor is not wanted?  
If you're going to create Text nodes with a constructor instead of 
document.createTextNode(), for example, you want a constructor that 
takes a string argument.  You don't want to have to use a no-arg 
constructor and then set the data property of the resulting object.  So 
if you make creating a no-arg constructor the default, then I think you 
also need to add a [NoDefaultConstructor] attribute to WebIDL

Also: What would happen for interfaces declared [NoInterfaceObject] and 
[Callback]?  Both of those would imply [NoDefaultConstructor], right?

> It also opens the door for overdue fixes, like defining the arguments
> these constructors should take, the document object that owns them,
> and starting the discussion about how to give them shorter names = )
WebIDL already allows constructor arguments to be defined.

Setting the ownerDocument correctly seems like a serious problem for 
default constructors for nodes.  The obvious approach is to pass a 
document to each constructor.  But then there are not default no-arg 
constructors, and they'd have to be declared anyway, which is already 
possible with WebIDL.

I don't know what you mean about shorter names.  WebIDL already gives 
spec authors the ability to use NamedConstructor to define shorthand 
factory names like Image() and Audio().

[Cut the stuff about inheriting from Array, but that would be a win if 
it could be done]

>>   I think we should get agreement from the editors of DOM Core
>> that that is what they want to do with NodeList and HTMLCollection.
> All I care about for the purposes of this discussion is that WebIDL
> doesn't preclude it, because I think some of us on TC39 fully intend
> to make Arrays truly sub-classable and I don't want to orphan the DOM
> types when we get there.
> Does DOM Core have editors right now?
annevk and ms2ger: the spec is under very active development right now.


Received on Thursday, 28 July 2011 19:11:44 UTC