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

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


>>> On Jul 25, 2012, at 9:13 PM, Dirk Schulze <dschu...@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 <dschu...@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 <aba...@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@lists.webkit.org
>>>>>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>>>>> _______________________________________________
>>>>> webkit-dev mailing list
>>>>> webkit-dev@lists.webkit.org
>>>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>>>> _______________________________________________
>>>> webkit-dev mailing list
>>>> webkit-dev@lists.webkit.org
>>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
webkit-dev mailing list

Reply via email to