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, 28 Jul 2011 14:18:49 -0700
Message-ID: <CANr5HFWcyMPG+22COApnt4Zjm5QqmS2yFP7=Zgqk9yDvaDUqmw@mail.gmail.com>
To: David Flanagan <dflanagan@mozilla.com>
Cc: Cameron McCormack <cam@mcc.id.au>, public-script-coord@w3.org, Brendan Eich <brendan@mozilla.com>
On Thu, Jul 28, 2011 at 12:11 PM, David Flanagan <dflanagan@mozilla.com> wrote:
> On 7/28/11 11:35 AM, Alex Russell wrote:
>> On Wed, Jul 27, 2011 at 11:07 PM, Cameron McCormack<cam@mcc.id.au>  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).

My only proposal here is that in the absence of [Constructor], one is
provided for you, it's not meant to preclude allowing more and more
expressive constructors with better argument handling.

> 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?

I like that.

> 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?

I don't think so. Just the effects of the absence of [Constructor] today.

> And what about interfaces for which a no-arg constructor is not wanted?

It's JS. Passing no args is the special case of passing args.

> 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.

Right, but it shouldn't blow up. These should be equivalent:

  var blank        = new Text("");
  var alsoBlank = new Text();

> 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?

I'm pretty sure that there's no need for [NoDefaultConstructor]. We
just need to explain the JS-side results if passing no args to the
ctor when you specify ctors that would otherwise take them.

>> 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.

My point was only that we need to do the work of defining what good,
useful args for Node and Element ctors should be. Yes, that's work for
DOM to do, but WebIDL lays the groundwork here.

> Setting the ownerDocument correctly seems like a serious problem for default
> constructors for nodes.

Nah. Image muddles through just fine. In any case, we can provide ways
to accomodate it, either through de-reference (getter-style):

   new d = new otherdoc.Div(...);

or by allowing the document to be passed into the args:

   var d = new Div({ ownerDocument: otherdoc });

> 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.

Do what Image does. Window has a document reference, and you dig the
ctors out of some window. Implicit is fine for the default case.

> 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().

Again, not WebIDL's problem per sae, but "HTMLDivElement" sucks vs.
"Div". Image and Audio are good precedents for Doing It Right (TM).

> [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.

Great! Thanks for the thoughtful feedback.
Received on Thursday, 28 July 2011 21:19:52 UTC

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