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

Fri Jan 25 09:14:03 PST 2013

On Fri, Jan 25, 2013 at 8:11 AM, Dirk Schulze <dschulze at 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 <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
>