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 <da...@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 <aba...@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 <aba...@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@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo/webkit-dev > > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev