W3C home > Mailing lists > Public > www-svg@w3.org > August 2001

RE: Multiple inheritance used in the SVG DOM interfaces.

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>
Message-ID: <ILEKJMELPMKMPCJDLJAAGEHACCAA.alex.fritze@crocodile-clips.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 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

> -----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

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:46:51 UTC