On Jul 25, 2012, at 3:50 PM, Adam Barth wrote: > On Wed, Jul 25, 2012 at 3:44 PM, Dirk Schulze <dschu...@adobe.com> 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? Here is a Wiki what we plan to do: http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IDL_interface_reorganization
It might not reflect all changes that we discussed during the SVG WG meeting today. Greetings, Dirk > > 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 <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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev