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

Dirk Schulze dschulze at adobe.com
Fri Jan 25 14:08:54 PST 2013 

On Jan 25, 2013, at 9:14 AM, Adam Barth <abarth at webkit.org> wrote:

> 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.

This sounds that you consider having "implements" in our WebIDL interpreter, or at least would not block adding this per se. This was my concern in the first place, since this is already in use in a lot of specifications (just with [NoInterfaceObject] as far as I saw).

> 
>> 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.

Well, it seems to be a bit different. Your poem would still be valid as long as it follows the grammar and can still be read, even if it does not make sense to you. You suggest not supporting everything from WebIDL, which means not accepting the full specified grammar. I think this is a concern where you would like to see limitations to the current grammar and which should be discussed.

> 
>> 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.

You suggest not implementing some corner cases. And as you say, we won't be able to support specifications relying on these corner cases. It rather seems you agree with my statement, even if it does not block former named specifications yet. I am not questioning your arguments to not support all corner cases of WebIDL. I am asking for an open discussion about particular cases on the relevant mailing lists (public-webapps for WebIDL) to address these concerns in the specification before leaving CR.

> 
>> 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.

This seems indeed a problem for WebIDL, since tests and testability is a requirement to leave CR. However, the WebApps WG might have a different thought.

Greetings,
Dirk

> 
> 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
>> 
> _______________________________________________
> 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