- From: Rik Cabanier <cabanier@gmail.com>
- Date: Wed, 2 Jul 2014 18:43:02 +0200
- To: Domenic Denicola <domenic@domenicdenicola.com>
- Cc: Brian Birtles <bbirtles@mozilla.com>, "public-fx@w3.org" <public-fx@w3.org>, Cameron McCormack <cam@mcc.id.au>, Boris Zbarsky <bzbarsky@mit.edu>
- Message-ID: <CAGN7qDBhHZiXt0Xn6ts2SQRyOPEZw_+ZMf=OO7vL0Yi96MMu3A@mail.gmail.com>
[top post intentional] Brian, as is clear from the different places where Domenic is getting pushback, it is not clear that his way will be the one forward. It's better that you wait until this is sorted out before changing the spec. On Wed, Jul 2, 2014 at 2:51 PM, Domenic Denicola < domenic@domenicdenicola.com> wrote: > From: Rik Cabanier [mailto:cabanier@gmail.com] > > > Don't do that just yet. > > Making them constructable will push their name in the global namespace. > As you know, exposing a new name is a Big Deal. It's also unclear if anyone > will call that constructor so this is just for theoretical purity. > > Instead, just mark them as [NoInterfaceObject] > > I intend to spend (a lot) more time on this thread later, but first: this > should not be true, even though it currently is in WebIDL. > [NoInterfaceObject] vs. [Constructor] should be entirely orthogonal > dimensions: > > - [Constructor] decides whether the class's constructor executes real > code, or just takes an unguessable secret/throws when it is not provided > and does implementation-specific processes depending on global state to > initialize itself. > - [NoInterfaceObject] decides whether the class's constructor is added to > the global. > > A class should be able to have a non-broken constructor without adding it > to the global object. We can fix this in WebIDL fairly easily. > > Also note, from WebIDL: > > > The [NoInterfaceObject] extended attribute SHOULD NOT be used on > interfaces that are not solely used as supplemental interfaces, unless > there are clear Web compatibility reasons for doing so. > > I haven't had time to look through the full of the OP, but perhaps the > issue can be solved by making some of the interfaces in question > supplemental interfaces, i.e. using `implements` instead of `:`, which > makes them more of a mixin rather than a class. In that case > [NoInterfaceObject] is appropriate (as it reinforces the mixin, not class, > nature). >
Received on Wednesday, 2 July 2014 16:43:30 UTC