On Wed, Jul 25, 2012 at 3:44 PM, Dirk Schulze <[email protected]> wrote: > On Jul 25, 2012, at 2:33 PM, Adam Barth 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*). > > SVG 2 will use WebIDL. Therefore we also reorganize our inheritance behavior. > Cameron, editor of WebIDL and SVG WG member, will update SVG 2 ED soon.
Do you anticipate adding properties or functions that return interfaces like SVGLocatable? Adam >> 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 <[email protected]> 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 >> [email protected] >> http://lists.webkit.org/mailman/listinfo/webkit-dev > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
