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