- From: Domenic Denicola <d@domenic.me>
- Date: Fri, 16 Jan 2015 19:06:56 +0000
- To: Ryosuke Niwa <rniwa@apple.com>, Anne van Kesteren <annevk@annevk.nl>
- CC: Dimitri Glazkov <dglazkov@google.com>, Erik Arvidsson <arv@google.com>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps <public-webapps@w3.org>
From: Ryosuke Niwa [mailto:rniwa@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.)
Received on Friday, 16 January 2015 19:07:28 UTC