- From: Johnny Stenback <jst@netscape.com>
- Date: Sun, 12 Aug 2001 17:42:21 -0700
- To: Alex Fritze <alex.fritze@crocodile-clips.com>
- CC: www-svg@w3.org, Chris Lilley <chris@w3.org>, Jon Ferraiolo <jferraio@adobe.com>
Alex Fritze wrote: > 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. > This is exactly what the SVG WG should've done, just like the DOM WG has done in all the DOM specs. > 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 >> >> >> > > -- jst
Received on Sunday, 12 August 2001 20:41:01 UTC