> On Apr 30, 2015, at 4:43 AM, Anne van Kesteren <ann...@annevk.nl> wrote: > > On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa <rn...@apple.com> wrote: >> The problem with "<shadow> as function" is that the superclass implicitly >> selects nodes based on a CSS selector so unless the nodes a subclass wants >> to insert matches exactly what the author of superclass considered, the >> subclass won't be able to override it. e.g. if the superclass had an >> insertion point with select="input.foo", then it's not possible for a >> subclass to then override it with, for example, an input element wrapped in >> a span. > > So what if we flipped this as well and came up with an imperative API > for "<shadow> as a function". I.e. "<shadow> as an actual function"? > Would that give us agreement?
We object on the basis that "<shadow> as a function" is fundamentally backwards way of doing the inheritance. If you have a MyMapView and define a subclass MyScrollableMapView to make it scrollable, then MyScrollableMapView must be a MyMapView. It doesn't make any sense for MyScrollableMapView, for example, to be a ScrollView that then contains MyMapView. That's has-a relationship which is appropriate for composition. - R. Niwa
