>>> > 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].
If it is possible to avoid the multiple inheritance, that would be best.
>>> > - class Element : public ContainerNode {
>>> > + class Element : public ContainerNode, public CSSRegion {
Another concern is that if CSSRegion has any virtual method, this will
increase sizeof(Element) by 8 byte in a 64 bit architecture. A virtual
method table pointer is needed for each parent class of multiple
inheritance. (c.f. https://bugs.webkit.org/show_bug.cgi?id=88528)
>>> > 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?
If CSSRegions does require multiple inheritance, I think
DOMInterface::interfaceName() sounds reasonable as Adam pointed out.
On Thu, Jul 26, 2012 at 6:54 AM, Adam Barth <aba...@webkit.org> wrote:
> According to WebIDL, every platform object has a "primary" interface,
> as defined by <http://www.w3.org/TR/WebIDL/#dfn-primary-interface>.
> As long as that's the case, DOMInterface::interfaceName() should be
> sufficient to figure out which JavaScript wrapper to use.
>
> Adam
>
>
> On Wed, Jul 25, 2012 at 2:44 PM, Darin Fisher <da...@google.com> wrote:
>> At least DOMInterface::interfaceName() is no where near as bad as COM's
>> QueryInterface.
>>
>> Provided we don't end up with any diamond inheritance hierarchies, we
>> shouldn't need
>> something as complicated as QueryInterface.
>>
>> -Darin
>>
>>
>>
>> On Wed, Jul 25, 2012 at 2:33 PM, Adam Barth <aba...@webkit.org> 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*).
>>>
>>> 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
>>
>>
--
Kentaro Hara, Tokyo, Japan (http://haraken.info)
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
