> 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"?

To start off, I can think of three major ways by which subclass wants to 
interact with its superclass:
1. Replace what superclass shows entirely by its own content - e.g. grab the 
device context and draw everything by yourself.
2. Override parts of superclass' content - e.g. subclass overrides virtual 
functions superclass provided to draw parts of the component/view.
3. Fill "holes" superclass provided - e.g. subclass implements abstract virtual 
functions superclass defined to delegate the work.

- R. Niwa

Reply via email to