[webkit-dev] Multiple inheritance in the DOM

[Darin Fisher]

At least DOMInterface::interfaceName() is no where near as bad as COM's
QueryInterface.

Provided we don't end up with any diamond inheritance hierarchies, we
shouldn't need
something as complicated as QueryInterface.

-Darin



On Wed, Jul 25, 2012 at 2:33 PM, Adam Barth <abarth at webkit.org> wrote:

> Eric Seidel points out that SVG uses multiple inheritance in its DOM
> interfaces.  However, the situation there is a bit different.
> Although SVGSVGElement implements SVGLocatable, there aren't any
> interfaces with methods that return SVGLocatable, which means we don't
> need to implement toJS(SVGLocatable*).
>
> He also points out that Node inherits from EventTarget, which already
> contains a virtual interfaceName() function similar to that used by
> Event.  That pushes us further towards using a common DOMInterface
> base class because introducing Region::interfaceName would mean that
> Element would see both EventTarget::interfaceName and
> Region::interfaceName.
>
> Adam
>
>
> On Wed, Jul 25, 2012 at 2:00 PM, Adam Barth <abarth at webkit.org> wrote:
> > The CSS Regions specification [1] defines a CSSOM interface named
> > Region, which can be mixed into interfaces for other objets that can
> > be CSS regions.  That means that Region introduces a form of multiple
> > inheritance into the DOM.  For example, Element implements Region but
> > Node does not implement Region.
> >
> > There's a patch up for review that implements Region using C++
> > multiple inheritance [2]:
> >
> > - class Element : public ContainerNode {
> > + class Element : public ContainerNode, public CSSRegion {
> >
> > One difficulty in implementing this feature how to determine the
> > correct JavaScript wrapper return for a given Region object.
> > Specifically, toJS(Region*) needs to return a JavaScript wrapper for
> > an Element if the Region pointer actually points to an Element
> > instance.
> >
> > We've faced a similar problem elsewhere in the DOM when implementing
> > normal single inheritance.  For example, there are many subclass of
> > Event and toJS(Event*) needs to return a wrapper for the appropriate
> > subtype.  To solve the same problem, CSSRule has a m_type member
> > variable and a bevy of isFoo() functions [3].
> >
> > A) Should we push back on the folks writing the CSS Regions
> > specification to avoid using multiple inheritance?  As far as I know,
> > this is the only instance of multiple inheritance in the platform.
> > Historically, EventTarget used multiple inheritance, but that's been
> > fixed in DOM4 [4].
> >
> > B) If CSS Regions continues to require multiple inheritance, should we
> > build another one-off RTTI replacement to implement toJS(Region*), or
> > should we improve our bindings to implement this aspect of WebIDL more
> > completely?
> >
> > One approach to implementing toJS in a systematic way is to introduce
> > a base class DOMInterface along these lines:
> >
> > class DOMInterface {
> > public:
> >     virtual const AtomicString& primaryInterfaceName() = 0;
> > }
> >
> > That returns the name of the primary interface (i.e., as defined by
> > WebIDL [5]).  When implementing toJS, we'd then call
> > primaryInterfaceName to determine which kind of wrapper to use.
> >
> > One downside of this approach is that it introduces a near-universal
> > base class along the lines of IUnknown [6] or nsISupports [7].  I
> > don't think any of us want WebKit to grow an implementation of
> > XPCOM...
> >
> > I welcome any thoughts you have on this topic.
> >
> > Thanks,
> > Adam
> >
> > [1] http://dev.w3.org/csswg/css3-regions/
> > [2] https://bugs.webkit.org/show_bug.cgi?id=91076
> > [3]
> http://trac.webkit.org/browser/trunk/Source/WebCore/css/CSSRule.h?rev=123653#L65
> > [4] http://www.w3.org/TR/dom/#node
> > [5] http://www.w3.org/TR/WebIDL/#dfn-primary-interface
> > [6]
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx
> > [7]
> https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsISupports
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120725/8037fd5f/attachment.html>