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

[Adam Barth]

On Fri, Jan 25, 2013 at 8:59 PM, Elliott Sprehn  wrote:
> On Fri, Jan 25, 2013 at 11:32 PM, Dirk Schulze  wrote:
>> ...
>> The problem is that SVGFitToViewBox and SVGZoomAndPan of the example above
>> are implemented by a lot of other interfaces as well. Supplemental is just
>> supposed to be set once per interface. That is why Supplemental doesn't work
>> for SVG. The alternative would be to implement the attributes and operations
>> of SVGFitToViewBox and SVGZoomAndPan into every class that implements them.
>> This would be a lot of code copies. And these are not the only interfaces
>> that would need to be merged.
>
> That's an issue of being DRY though, which we can certainly solve in WebKit.
> I don't think Adam has an issue with extending webkit IDL to help with that,
> or at least I'd hope not.

Nope.  :)

> We could probably use multiple inheritance in C++ and copy/paste the idl
> defs, or add some new IDL feature for it.

We already have support for that in WebKitIDL (albeit using a
different syntax).  See, for example,

http://trac.webkit.org/browser/trunk/Source/WebCore/svg/SVGGElement.idl

The problem arises if there's an API somewhere that returns, e.g.,
SVGTransformable.  When implementing such an API, we wouldn't know
which concrete type we actually have and would need to use something
like QueryInterface to find out.  Fortunately, no such APIs exist
currently.

I should also say that we've caved slightly on this stance for
interaces like Event that have many subclasses and are often returned
by APIs.  The way we handle this case is by introducing a virtual
function called "interfaceName" that returns the name of the
most-derived interface that the concrete object supports:

http://trac.webkit.org/browser/trunk/Source/WebCore/dom/Event.h#L121

At runtime, we use that information to static_cast the C++ object
appropriately.  It's not as general as QueryInterface, and I'm not
sure how far we want to extend that mechanism given that it's
relatively slow.  Certainly we wouldn't want to introduce a universal
base class (a la IUnknown or nsISupports) as required in COM and
XPCOM, respectively.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Elliott Sprehn]

On Fri, Jan 25, 2013 at 11:32 PM, Dirk Schulze  wrote:

> ...
> The problem is that SVGFitToViewBox and SVGZoomAndPan of the example above
> are implemented by a lot of other interfaces as well. Supplemental is just
> supposed to be set once per interface. That is why Supplemental doesn't
> work for SVG. The alternative would be to implement the attributes and
> operations of SVGFitToViewBox and SVGZoomAndPan into every class that
> implements them. This would be a lot of code copies. And these are not the
> only interfaces that would need to be merged.
>

That's an issue of being DRY though, which we can certainly solve in
WebKit. I don't think Adam has an issue with extending webkit IDL to help
with that, or at least I'd hope not.

We could probably use multiple inheritance in C++ and copy/paste the idl
defs, or add some new IDL feature for it.

- E
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Dirk Schulze]

On Jan 25, 2013, at 8:16 PM, Elliott Sprehn  wrote:

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

As far as I understood it, HTMLInputElementFileSystem extends HTMLInputElement. 
In WebIDL it would be:

HTMLInputElement implements HTMLInputElementFileSystem;

The problem is that SVGFitToViewBox and SVGZoomAndPan of the example above are 
implemented by a lot of other interfaces as well. Supplemental is just supposed 
to be set once per interface. That is why Supplemental doesn't work for SVG. 
The alternative would be to implement the attributes and operations of 
SVGFitToViewBox and SVGZoomAndPan into every class that implements them. This 
would be a lot of code copies. And these are not the only interfaces that would 
need to be merged.

Greetings,
Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Elliott Sprehn]

On Fri, Jan 25, 2013 at 8:09 PM, Dirk Schulze  wrote:

>
> On Jan 25, 2013, at 4:23 PM, Maciej Stachowiak  wrote:
>
> >
> > On Jan 25, 2013, at 4:13 PM, Adam Barth  wrote:
> >
> >> On Fri, Jan 25, 2013 at 2:08 PM, Dirk Schulze 
> wrote:
> >>> On Jan 25, 2013, at 9:14 AM, Adam Barth  wrote:
>  On Fri, Jan 25, 2013 at 8:11 AM, Dirk Schulze 
> 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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Dirk Schulze]

On Jan 25, 2013, at 4:23 PM, Maciej Stachowiak  wrote:

> 
> On Jan 25, 2013, at 4:13 PM, Adam Barth  wrote:
> 
>> On Fri, Jan 25, 2013 at 2:08 PM, Dirk Schulze  wrote:
>>> On Jan 25, 2013, at 9:14 AM, Adam Barth  wrote:
 On Fri, Jan 25, 2013 at 8:11 AM, Dirk Schulze  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
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Maciej Stachowiak]

On Jan 25, 2013, at 4:13 PM, Adam Barth  wrote:

> On Fri, Jan 25, 2013 at 2:08 PM, Dirk Schulze  wrote:
>> On Jan 25, 2013, at 9:14 AM, Adam Barth  wrote:
>>> On Fri, Jan 25, 2013 at 8:11 AM, Dirk Schulze  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.

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.

(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").

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Adam Barth]

On Fri, Jan 25, 2013 at 2:08 PM, Dirk Schulze  wrote:
> On Jan 25, 2013, at 9:14 AM, Adam Barth  wrote:
>> On Fri, Jan 25, 2013 at 8:11 AM, Dirk Schulze  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.

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

In this analogy, WebKit is like a collection of poems.  We can choose
not to include a terrible poem in our collection without needing to
form a judgement about the language in which the poem was written.

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

You're welcome to write whatever specifications you like.  I'm just
hoping to save you the effort by telling you that we're not going to
implement a feature that requires us to build COM.

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

I have no concerns with WebIDL.  I have concerns with specifications
that require an implementation of QueryInterface regardless of whether
they're written in WebIDL or in English.

Adam


>>> On Jul 25, 2012, at 9:13 PM, Dirk Schulze  wrote:
 On Jul 25, 2012, at 3:50 PM, Adam Barth wrote:
> On Wed, Jul 25, 2012 at 3:44 PM, Dirk Schulze  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
>>>

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

[Adam Barth]

On Fri, Jan 25, 2013 at 11:28 AM, Glenn Adams  wrote:
> On Fri, Jan 25, 2013 at 10:14 AM, Adam Barth  wrote:
>> 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.
>
> Speaking of implementing WebIDL (in the context of a spec that normatively
> requires its support, e.g., CSSOM), what is your position on whether WK
> will/should support the following? In the test at [1], neither of these are
> currently supported, or at least don't yield expected results.
>
> WebIDL 4.4.1 [2] states:
>
> The interface object for a given non-callback interface is a function
> object.
>
> WebIDL 4.4.3 [3] states:
>
> If the [NoInterfaceObject] extended attribute was not specified on the
> interface, then the interface prototype object must also have a property
> named “constructor” with attributes { [[Writable]]:true, [[Enumerable]]:
> false, [[Configurable]]: true } whose value is a reference to the interface
> object for the interface.

I don't have a strong opinion on those topics.  I'm happy to review
patches in this area.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Dirk Schulze]

On Jan 25, 2013, at 9:14 AM, Adam Barth  wrote:

> On Fri, Jan 25, 2013 at 8:11 AM, Dirk Schulze  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  wrote:
>>> On Jul 25, 2012, at 3:50 PM, Adam Barth wrote:
 On Wed, Jul 25, 2012 at 3:44 PM, Dirk Schulze  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 Wi

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

[Glenn Adams]

On Fri, Jan 25, 2013 at 10:14 AM, Adam Barth  wrote:

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

Speaking of implementing WebIDL (in the context of a spec that normatively
requires its support, e.g., CSSOM), what is your position on whether WK
will/should support the following? In the test at [1], neither of these are
currently supported, or at least don't yield expected results.

WebIDL 4.4.1 [2] states:

The interface object for a given non-callback
interface is
a function object
.

WebIDL 4.4.3 [3] states:

If the 
[NoInterfaceObject]
extended
attribute was not specified on the interface, then the interface prototype
object must also have a property named “constructor” with attributes
{ [[Writable]]:true, [[Enumerable]]: false, [[Configurable]]: true } whose
value is a reference to the interface object for the interface.

[1]
http://hg.csswg.org/test/raw-file/3d8f9c12b1c8/contributors/gadams/incoming/cssom/cssstylerule-interface.xht
[2] http://dev.w3.org/2006/webapi/WebIDL/#interface-object
[3] http://dev.w3.org/2006/webapi/WebIDL/#interface-prototype-object

Regards,
Glenn
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Adam Barth]

On Fri, Jan 25, 2013 at 8:11 AM, Dirk Schulze  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  wrote:
>> On Jul 25, 2012, at 3:50 PM, Adam Barth wrote:
>>> On Wed, Jul 25, 2012 at 3:44 PM, Dirk Schulze  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  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
>

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

[Dirk Schulze]

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.

Greetings,
Dirk

[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  wrote:

> 
> On Jul 25, 2012, at 3:50 PM, Adam Barth wrote:
> 
>> On Wed, Jul 25, 2012 at 3:44 PM, Dirk Schulze  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  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;
>>