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

[Dirk Schulze]

On Jan 25, 2013, at 4:23 PM, Maciej Stachowiak <mjs at apple.com> wrote:

> 
> On Jan 25, 2013, at 4:13 PM, Adam Barth <abarth at webkit.org> wrote:
> 
>> On Fri, Jan 25, 2013 at 2:08 PM, Dirk Schulze <dschulze at adobe.com> wrote:
>>> 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).
>> 
>> WebKit doesn't have an WebIDL interpretor.  We have a WebKitIDL
>> compiler.  If you spec something that requires a QueryInterface-like
>> mechanism in the implementation, we will not implement it regardless
>> of what language you write the specification in.  It's a conscious
>> design decision not to implement a COM-like (or XPCOM-like) system.
> 
> Setting aside the more general question, does the SVG2 set of interfaces effectively require a QueryInterface-like mechanism? What limitations, if any, on the use of "implements" would a spec have to follow to dodge this bullet? SVG2 is still evolving, so I suspect it could adjust its use of "implements" if it's an issue for us.

SVG2 does not require any inter process communication. The QueryInterface was an example of Adam what we should not implement. SVG2 uses WebIDL's "implements" statement for [NoInterfaceObject] interfaces, as the HTML specification is doing it. But SVG uses multiple "implements" statements per interface:

interface SVGViewSpec
 {
  readonly attribute SVGTransformList transform;
  readonly attribute SVGElement viewTarget;
  readonly attribute DOMString viewBoxString;
  readonly attribute DOMString preserveAspectRatioString;
  readonly attribute DOMString transformString;
  readonly attribute DOMString viewTargetString;
};
SVGViewSpec implements SVGFitToViewBox;
SVGViewSpec implements SVGZoomAndPan;

SVGFitToViewBox and SVGZoomAndPan are both NoInterfaceObjects.

I hope that I am not mistaken and that this is not what you mean with QueryInterface.

> 
> If SVG2 does happen to avoid the problem, would we want to use "implements" as the syntax in WebKitIDL or would we want a different syntax? I could see arguments either way.

I think it would be desirable to follow WebIDL and the syntax of this specifications as long as the goals overlap.

> 
> (FWIW I agree that we don't want to end up in a position where we'd have to implement a QI-like mechanism for the sake of the bindings, but I can't tell from the conversation so far if this is an immediate issue with SVG2, or just a possible issue with other potential uses of "implements").

If I understand Adam correctly, then the later. If there are problems with the SVG2 specification, then I am happy to talk with the SVG WG and find solutions. But the SVG WG still needs to cover the behavior of SVG 1.1 as much as possible.

Greetings,
Dirk

> 
> Regards,
> Maciej
>