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
