[webkit-dev] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)

[Adam Barth]

On Fri, Jan 25, 2013 at 8:59 PM, Elliott Sprehn <esprehn at chromium.org> wrote:
> On Fri, Jan 25, 2013 at 11:32 PM, Dirk Schulze <dschulze at adobe.com> wrote:
>> ...
>> The problem is that SVGFitToViewBox and SVGZoomAndPan of the example above
>> are implemented by a lot of other interfaces as well. Supplemental is just
>> supposed to be set once per interface. That is why Supplemental doesn't work
>> for SVG. The alternative would be to implement the attributes and operations
>> of SVGFitToViewBox and SVGZoomAndPan into every class that implements them.
>> This would be a lot of code copies. And these are not the only interfaces
>> that would need to be merged.
>
> That's an issue of being DRY though, which we can certainly solve in WebKit.
> I don't think Adam has an issue with extending webkit IDL to help with that,
> or at least I'd hope not.

Nope.  :)

> We could probably use multiple inheritance in C++ and copy/paste the idl
> defs, or add some new IDL feature for it.

We already have support for that in WebKitIDL (albeit using a
different syntax).  See, for example,

http://trac.webkit.org/browser/trunk/Source/WebCore/svg/SVGGElement.idl

The problem arises if there's an API somewhere that returns, e.g.,
SVGTransformable.  When implementing such an API, we wouldn't know
which concrete type we actually have and would need to use something
like QueryInterface to find out.  Fortunately, no such APIs exist
currently.

I should also say that we've caved slightly on this stance for
interaces like Event that have many subclasses and are often returned
by APIs.  The way we handle this case is by introducing a virtual
function called "interfaceName" that returns the name of the
most-derived interface that the concrete object supports:

http://trac.webkit.org/browser/trunk/Source/WebCore/dom/Event.h#L121

At runtime, we use that information to static_cast the C++ object
appropriately.  It's not as general as QueryInterface, and I'm not
sure how far we want to extend that mechanism given that it's
relatively slow.  Certainly we wouldn't want to introduce a universal
base class (a la IUnknown or nsISupports) as required in COM and
XPCOM, respectively.

Adam