> On Dec 7, 2013, at 4:38 PM, Dominic Cooney <[email protected]> wrote: > >> On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa <[email protected]> wrote: >> On Dec 5, 2013, at 10:09 PM, Hajime Morrita <[email protected]> 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.
The problem here is that until such hooks are well defined, inheriting from builtin elements doesn't make any sense. So let's not support that until such proposal is made and implemented. In addition, consider how inheriting "views" work in AppKit, UIKit, .net and MFC. When a view T inherits from another view S, T doesn't simply put S into a subregion of T; S intrudes into T's view and modifies what's been displayed or places extra content after or before T draws itself. I have a hard time understanding how this bizarre mixture of inheritance and composition is considered as the minimal subset of features while adding one optional argument to document.register to eliminate the most common boilerplate is considered as "building a framework" and "bundling" orthogonal features. Where did use cases and developer ergonomics go? - R. Niwa
