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. Adam >>> 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
