[webkit-dev] Multiple inheritance in the DOM

[Adam Barth]

According to WebIDL, every platform object has a "primary" interface,
as defined by <http://www.w3.org/TR/WebIDL/#dfn-primary-interface>.
As long as that's the case, DOMInterface::interfaceName() should be
sufficient to figure out which JavaScript wrapper to use.

Adam


On Wed, Jul 25, 2012 at 2:44 PM, Darin Fisher <darin at google.com> wrote:
> 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
>
>