> 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

Reply via email to