- From: Alex Fritze <alex.fritze@crocodile-clips.com>
- Date: Sun, 12 Aug 2001 16:51:43 +0100
- To: <www-svg@w3.org>
- Cc: "Johnny Stenback" <jst@netscape.com>, "Chris Lilley" <chris@w3.org>, "Jon Ferraiolo" <jferraio@adobe.com>
In Mozilla's SVG implementation we have implemented the SVG DOM by keeping one single principal inheritance thread for the interfaces & 'promising' to implement all the other interfaces that would otherwise be mixed into the interface tree. E.g. we inherit the SVGCircleElement interface directly from SVGElement (which in turn inherits from Element and Node) and 'promise' that every object implementing SVGCircleElement also implements the interfaces SVGStylable, SVGTransformable etc. IMO flattening interfaces is ok for untyped languages like js, but doesn't do COM/C++ justice. If there is one flat interface per SVG entity, you lose all polymorphic capabilities. How are you going to implement functions like Translate(SVGTransformable*)? With flattened interfaces you'd need Translate(IUnknown*) (or XPCOM: Translate(nsISupports*) ) and then QI for every possible interface that supports SVGTransformable functionality. Alex -------------------------------------------------------------- alex fritze crocodile clips ltd [w] www.croczilla.com/svg 11 randolph place [e] alex.fritze@crocodile-clips.com edinburgh [t] +44 (0) 131 226 3263 eh3 7ta [f] +44 (0) 131 226 1522 scotland -------------------------------------------------------------- > -----Original Message----- > From: www-svg-request@w3.org [mailto:www-svg-request@w3.org]On > Behalf Of Jon > Ferraiolo > Sent: 11 August 2001 19:04 > To: Johnny Stenback > Cc: Chris Lilley; www-svg@w3.org > Subject: Re: Multiple inheritance used in the SVG DOM interfaces. > > > 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. > > 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. .... > > 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. > > Jon Ferraiolo > SVG 1.0 Editor > jferraio@adobe.com > > At 03:23 PM 8/10/01 -0700, Johnny Stenback wrote: > > Chris Lilley wrote: > > > Johnny Stenback wrote: > > > Does silence mean that nobody cares if the SVG DOM interfaces are > un-implementable in COM like environments? > > > No, it means that there was some discussion recently between Philippe, Jon > and myself and that it turns out that Adobe has in fact > implemented SVG DOM > in a COM environment. I have asked them for some more details of > > > this. > > Any resolution to this yet? I see the SVG spec moving forward, but I don't > see how that can happen w/o resolving this issue? > > > -- > jst > >
Received on Sunday, 12 August 2001 11:58:00 UTC