- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 08 Jan 2014 11:17:10 -0500
- To: public-webapps@w3.org
On 1/6/14 8:52 PM, Goktug Gokdogan wrote:
> function MyCustomElement() {};
> MyCustomElement.prototype = Object.create(HTMLElement.prototype);
> document.appendChild(new MyCustomElement());
If this were actually using ES6 classes (and if HTMLElement were
constructible), this would in fact work. The issue is that simply
setting your proto is not actually the same thing as subclassing when
objects need to have private state and hence are branded.
> I guess the reason I was thinking that way was mostly historical
> reasons. In OO platforms, defining your own widget has been just a
> matter of extending a base class.
In this case it's more like you implemented an interface but the
appendChild method expects a particular implementation of that interface....
> All this may sound specific to GWT but actually I think it is more about
> object orientation and I can imagine similar issues will be hit with
> classes in ES6, Dart and others.
ES6 classes will actually end up working correctly here, in that you
will be able to define an ES6 class extending a constructible DOM class,
then call its constructor, and that will work correctly.
> function MyCustomElement {
> document.initElement(this); // let's the browser do whatever needed
> }
This actually isn't very feasible, because the "this" is already the
wrong sort of object here and can't be mutated in-place (e.g. the right
sort of object needs to be in a different arena in some implementations).
Again, ES6 classes, once implemented, solve this problem by delegating
@@construct to the superclass correctly.
-Boris
Received on Wednesday, 8 January 2014 16:17:40 UTC