RE: Recent TAG impacts on APIs

On April 17, 2014 at 2:25:38 PM, Domenic Denicola (domenic@domenicdenicola.com) wrote:
> From: Marcos Caceres  
>  
> > 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.

If I had a penny for every time... 

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

Not to mention the idea of having "interfaces"... separate battle, but I think it's important to make the distinction between a class and an interface. 

Thanks for the clarifications!

Received on Thursday, 17 April 2014 20:05:25 UTC