[webkit-dev] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)

Dirk Schulze dschulze at adobe.com
Fri Jan 25 08:11:43 PST 2013

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? Have the concerns been submitted to the editor and the WG working on the WebIDL specification?

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. Not implementing WebIDL could not only block this specification in particular, but also all other specs relying on it. 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.


[1] https://svgwg.org/svg2-draft/single-page.html#types-InterfaceSVGGraphicsElement
[2] http://www.w3.org/TR/WebIDL/#NoInterfaceObject

On Jul 25, 2012, at 9:13 PM, Dirk Schulze <dschulze at 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 <dschulze at 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 <abarth at 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 at lists.webkit.org
>>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

More information about the webkit-dev mailing list