From: Ryosuke Niwa [mailto:rn...@apple.com]
> However, nobody has suggested a design that satisfies both of our
> requirements: using ES6 constructor for element initialization
Hi Ryosuke,
Could you say more about why this is a requirement? In particular, why you
require that developers type
```js
class MyElement extends HTMLElement {
constructor(htmlElementConstructorOptions, ...extraArgs) {
super(htmlElementConstructorOptions);
// initialization code here, potentially using extraArgs for non-parser
cases
}
}
```
instead of them typing
```js
class MyElement extends HTMLElement {
[Element.create](...extraArgs) {
// initialization code here, potentially using extraArgs for non-parser
cases
}
}
```
? This kind of inversion-of-control pattern is, as I've tried to point out,
fairly common in UI frameworks and in programming in general. "Don't call me,
I'll call you" is the catchphrase, explained in
https://en.wikipedia.org/wiki/Hollywood_principle. As the article says:
> It is a useful paradigm that assists in the development of code with high
> cohesion and low coupling that is easier to debug, maintain and test. ...
> Most beginners are first introduced to programming from a diametrically
> opposed viewpoint. ... [But] It would be much more elegant if the programmer
> could concentrate on the application [...] and leave the parts common to
> every application to something else.
If this is a formal objection-level complaint, I'm motivated to understand why
you guys don't think this software engineering best-practice applies to custom
elements. It seems like a textbook example of where inversion-of-control
applies.
(BTW I really recommend that Wikipedia article as reading for anyone
interested; it ties together in one place a lot of wisdom about object-oriented
design that I've had to absorb in bits and pieces throughout the years. I wish
I'd seen it earlier.)
