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

Reply via email to