- From: Brian Kardell <bkardell@gmail.com>
- Date: Thu, 30 Apr 2015 17:29:32 -0400
- To: Ryosuke Niwa <rniwa@apple.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, Hayato Ito <hayato@chromium.org>, WebApps WG <public-webapps@w3.org>, Jan Miksovsky <jan@component.kitchen>
On Thu, Apr 30, 2015 at 2:00 PM, Ryosuke Niwa <rniwa@apple.com> wrote: > >> On Apr 30, 2015, at 4:43 AM, Anne van Kesteren <annevk@annevk.nl> wrote: >> >> On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa <rniwa@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 > 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? -- Brian Kardell :: @briankardell :: hitchjs.com
Received on Thursday, 30 April 2015 21:29:59 UTC