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 <[email protected]> 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 <[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
