Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)

On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa <rniwa@apple.com> wrote:

> On Dec 5, 2013, at 10:09 PM, Hajime Morrita <morrita@google.com> wrote:
> > On inheritance around HTMLElement family, there seems to be a confusion
> between interface side inheritance and implementation side inheritance.
>
> Right.  Differentiating the two is very important.
>
> > For Custom Elements, the inheritance is not only about interface, but
> also about implementation. The implementation is more complex and flux in
> detail, thus worth being shared between different elements. Actually, the
> implementation of built-in HTML elements, which are usually done in C++,
> uses inheritance heavily, at least Blink and (I believe) WebKit.
>
> The reason we can use inheritance heavily is because we have control over
> both parent and child classes, and there are careful distinctions between
> public, protected, and private member functions and member variables in
> those classes.
>
> Unfortunately, custom elements can't easily inherit from these builtin
> HTML elements because builtin elements do not provide "protected"
> functions, and they don't expose necessary hooks to override internal
> member functions to modify behaviors.
>

Built-in HTML elements have lots of hooks to modify their behaviour (for
example, HTMLVideoElement's autoplay attribute.) The analogy is extending a
Java class which has private and public final members, but no protected or
public non-final ones.

If someone were to make proposals about adding more hooks to the web
platform to enable more subtyping use cases (for example, a protocol for
participating in form submission) I would look forward to working with them
on those proposals.


> Evidently, in the current Custom Elements specification, the interface is
> inherited but the implementation (DOM) is composed via shadow element.
>

There is a lot more to the implementation of an element than what is in its
Shadow DOM. By analogy, Blink has lots of C++ code implementing built-in
elements and relatively few of them have Shadow DOM. It is also incorrect
to think all elements have Shadow DOM.


> In fact, we've come to a conclusion that shadow element is an unnecessary
> complexity because composition is the preferred mechanism to build complex
> objects on the Web, and if someone is using inheritance, then the subclass
> should have access to the shadow DOM of the superclass directly instead of
> it being magically projected into the shadow element.  In fact, this is how
> inheritance works in other GUI frameworks such as Cocoa, .net, etc…
>
> Additionally, we don't have something like shadow element inside Blink or
> WebKit for our builtin elements.  If our goal is to explain and describe
> the existing features on the Web platform, then we sure shouldn't be
> introducing this magical mechanism.
>
> If we had a subclass that truly wanted to contain its superclass in some
> non-trivial fashion, then we should be using composition instead.  If the
> container class needed to forward some method calls and property accesses
> to the contained element, then it should just do.  And providing a
> convenient mechanism to forward method calls and property access in
> JavaScript is an orthogonal problem we should be solving anyway.
>
> - R. Niwa
>
>
>


-- 
<http://goto.google.com/dc-email-sla>