> 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. - R. Niwa
