> On Apr 30, 2015, at 2:44 PM, Ryosuke Niwa <rn...@apple.com> wrote: > > >> On Apr 30, 2015, at 2:29 PM, Brian Kardell <bkard...@gmail.com> wrote: >> >> On Thu, Apr 30, 2015 at 2:00 PM, Ryosuke Niwa <rn...@apple.com> wrote: >>> >>>> 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. >> >> >> Is there really a hard need for inheritance over composition? Won't >> composition ability + an imperative API that allows you to properly >> delegate to the stuff you contain be just fine for a v1? > > Per resolutions in F2F last Friday, this is a discussion for v2 since we're > definitely not adding multiple generations of shadow DOM in v1. > > However, we should have a sound plan for inheritance in v2 and make sure our > imperative API is forward compatible with it. So the goal here is to come up > with some plan for inheritance so that we can be confident that our > inheritance API is not completely busted.
Sorry, I meant to say our *imperative* API is not completely busted. - R. Niwa
