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

Elliott Sprehn esprehn at chromium.org
Fri Jan 25 20:16:02 PST 2013

On Fri, Jan 25, 2013 at 8:09 PM, Dirk Schulze <dschulze at adobe.com> wrote:

> 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.
Since they're NoInterfaceObjects we can just merge the idl into the file in
WebKit or use Supplemental in WebkitIDL. You've written it with multiple
implements to be DRY in the WebIDL, that's not a problem for WebKit.

See: HTMLInputElementFileSystem.

- E
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130125/0b2f458d/attachment.html>

More information about the webkit-dev mailing list