RE: Recent TAG impacts on APIs

From: Marcos Caceres <w3c@marcosc.com>

> Do you mean with sub-classing host objects? As in:
>
> class MyClass extends HTMLElement{ ... }?

Yeah, exactly. More importantly, what would HTMLElement have to specify to allow such subclassing?

For example, right now subclassing is impossible because trying to do `HTMLElement.call(this)` in a subclass constructor will immediately throw an "incompatible object" type error.

>From a nitty-gritty ES6 perspective, this involves things like:

- Defining how HTMLElement.prototype[Symbol.create] returns an uninitialized-but-branded object
- Defining how HTMLElement (the constructor itself) checks that the brand is present, then does the actual initialization
- Defining what are the internal properties that being branded gives you, so that methods of HTMLElement can be specified as manipulating those internal properties, and can thus be applied to any properly-branded object (including subclass instances).
- (Of course, the above presupposes you plan on defining a constructor for HTMLElement---that's a given!)

The hope is to provide a combination of guidance and extensions to WebIDL to make this kind of thing automatic and easy, so nobody else has to go through the kind of learnings and pain I went thruough while making Promises subclassable :P

> Well, none I guess in the case above. But it does support inheritance:
> http://heycam.github.io/webidl/#dfn-inherit

Unfortunately the way that inheritance takes place is entirely inexplicable from a JS point of view. This feels similar to me how lots of objects on the web platform are somehow constructed and instances of them exist, despite not having constructors. Lots of classes on the web platform somehow inherit from other classes, despite those base classes not actually allowing subclassing.

Received on Thursday, 17 April 2014 18:26:05 UTC