Re: Multiple inheritance used in the SVG DOM interfaces.

Jon Ferraiolo <jferraio@adobe.com> wrote:
 > Adobe takes the SVG IDL and runs a flattening process to expand all
 > base classes before sending it through the MS COM tools, such as midl.
 > This is really a very simple process. If the W3C were to provide COM
 > bindings for its various DOMs, this is the approach that would be used
 > in the COM bindings.
 >

What? You take an interface and you simply grab the methods from all 
inherited methods (except for one interface?) and jam them into a new 
interface and you call that the COM version of the interface in question?

Lets look at an example here, what happens to the attributes and methods 
that are defined in inherited interfaces, like SVGLangSpace, you simply 
throw that type away and just copy the definitions in SVGLangSpace into 
all interfaces that inherit SVGLangSpace? Say I wanto write a method 
that does some checking on xml:lang used on a SVG element using the SVG 
DOM, from looking at the spec, I would imagine that I could write a 
method that takes an argument of type SVGLangSpace (I could absolutely 
do this in Java), and then I could do my processing based on that 
argument. If the SVG WG's suggestion for COM implementations is to 
flatten all methods in SVGLangSpace into all interfaces that inherit 
from SVGLangSpace, then the type SVGLangSpace is lost (or meaningless if 
it's kept around) and there's no common type I could cast/QI to that 
would let me make a call into a method that was defined in the 
SVGLangSpace interface. There's no way I can write one single method 
that is capable of calling a method that is defined in the SVGLangSpace 
interface in the SVG DOM spec w/o templetizing my method to work with 
all the different types that originally inherited SVGLangSpace.

This hardly seems like a clean solution to me.

 > Note that W3C documented ECMAScript bindings in effect do the same
 > sort of flattening because ECMAScript doesn't even support single
 > inheritance. For example, here is an excerpt from the ECMAScript
 > language binding for DOM level 2 core for the Element interface:
 >
 > Object Element
 > Element has the all the properties and methods of the Node object as
 > well as the properties and methods defined below. ....
 >

Doing this for ECMAScript is perfectly fine since the ECMAScript 
language is loosely typed, there's not really a concept of types, 
casting, vtables or anything like that (btw, ECMAScript does in a way 
support single inheritance through it's prototype model). In ECMAScript 
all object method/property lookups are dynamic and type doesn't really 
matter.

But in an environment like COM using a tightly typed language like C++ 
you simply can't do that, you loose valuable types and unless you define 
exactly how this flattening is supposed to be done then you also loose 
compatibility between implementations.

 > There is indeed a viable approach to implementing the SVG DOM in COM
 > environments and at least one implementation has successfully
 > implemented this approach. The flattening approach used to implement
 > COM interfaces matches the approach used to implement ECMAScript
 > interfaces.
 >

So the existing COM implementation of the SVG DOM doesn't have an 
interface for SVGLangSpace, or any of the other types that are inherited 
by other SVG DOM implementations? Or are the types kept around and 
implemented by objects that implement interfaces that inherit multiple 
interfaces in the SVG DOM spec, in addition of implementing the 
interface that contains the flattened view of the inherited interfaces?

I still don't see a clean COM/C++ friendly non-lossy solution for this 
problem.

 > Jon Ferraiolo
 > SVG 1.0 Editor
 > jferraio@adobe.com


-- 
jst

Received on Monday, 20 August 2001 23:41:43 UTC