On Fri, Jan 25, 2013 at 8:11 AM, Dirk Schulze <dschu...@adobe.com> wrote: > This is a followup to the multiple inheritance discussion. > > Adam, I checked the IDL files on SVG2 [1]. The interfaces for SVG2 do not > have multiple inheritances of interfaces that are exposed to bindings. But > SVG2 still uses the "implements" statement for "[NoInterfaceObject]" > interfaces [2]. This should at least address your initial concern not to > inherit from different interfaces exposed to bindings. > > However, during a discussion on IRC I got the impression that we do not plan > to support the "implements" statement because it can do "weird" things. If > this is right, I would like to understand why this is the case?
We don't intend to support all the possible things that you can do with "implements." With "implements", you can define arbitrarily complicated relationships between interfaces, including some that can be implemented only with a QueryInterface-like mechanism. We're not going to implement QueryInterface, so we're not going to implement any specifications that require it. >Have the concerns been submitted to the editor and the WG working on the >WebIDL specification? I haven't submitted my concerns. There's nothing particularly wrong with the WebIDL language, just like there's nothing particularly wrong with English just because you can use it to write a terrible poem. > More and more specifications describe interfaces by using WebIDL, including > HTML5, Canvas, SVG2, Filter Effects and CSS Masking. If there are general > concerns on WebIDL, they should be addressed on the spec before leaving CR > state. I don't have any concerns with the WebIDL language. The WebIDL language is just a mechanism for writing precise specifications. > Not implementing WebIDL could not only block this specification in > particular, but also all other specs relying on it. That's nonsense. Just because we don't implement some crazy corner case of WebIDL that doesn't mean that we're unable to implement *all* specs that reply upon it. For example, HTML and DOM use WebIDL and we're able to implement them just fine. > Or maybe worst, it gets a recommendation and we do not follow web standards > anymore. It would be great to hear a clarification. Maybe it is just a > misunderstanding on my site. There's no experiment that you can run using web content to detect whether we implement WebIDL. All you can detect is whether we implement particular specifications that use WebIDL. We can just simply not implement the specifications that require COM-like implementations and we can continue to lead a happy life. Adam > On Jul 25, 2012, at 9:13 PM, Dirk Schulze <dschu...@adobe.com> wrote: >> 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 > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
