Re: [webcomponents] Feedback for web components spec from a GWT experiment

On Wed, Jan 8, 2014 at 8:17 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> 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.
>
>
Yes, I'm not exactly extending but I would not call it as implementing an
interface as well :)
Is it really part of the plans (i.e. making HTMLElement constructible)? If
it is, is it going to work with some native support from browser? That's
what I'm trying to emulate right now. I suggested document.initElement
because provides me a way to emulate this.


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