Re: SVGLists of type DOMString

Steve,
The DOM is defined using IDL, and IDL has a thing called an Object which is
the implicit base class upon which all other classes/interfaces inherit. At
least that is my understanding. Thus, from a DOM perspective and an IDL
perspective, DOMString does implicitly inherit from Object.

You point out that there is an Object class in Java. There is also one in
ECMAScript.

If I am right with the analysis, then it seems to me that it would be
incorrect to change the SVG spec to introduce an SVGString interface just
so it can inherit from Object since DOMString does this already. It looks
to me like C++ implementations of any DOM (SVG or otherwise) need to create
a base class Object in order to conform to the model which is supported by
IDL, Java and ECMAScript. If my analysis is wrong, then please correct me.

Jon Ferraiolo
SVG Editor
Adobe Systems Incorporated

At 03:13 PM 8/2/00 -0700, Steve Dickson wrote:
>Per the newly released Candidate Recommendation of Auguest 2, 2000. 
>Section 4.3, Basic DOM interfaces, describes interface SVGTests.  This
>interface includes an attribute requiredFeatures which is described as
>follows:
>
>"SVGList requiredFeatures
>Corresponds to attribute requiredFeatures on the given element. The
>various methods from SVGList, which are defined to accept
>parameters and return values of type Object, must receive parameters of
>type DOMString and return values of type DOMString."
>
>This implicitly requires DOMString to inherit from Object.  In a Java
>implementation, this would not be a problem, since all classes
>automatically inherit from Object.  However, C++ doesn't have an inherent
>Object class.  C++ implementations must create their own class Object, and
>all classes which can be list members then derive from the Object class. 
>By stipulating that DOMString can now be inserted into a list, DOMString
>must derive from type Object.  This requires a change to the DOM.   
>
>I think it's a bad idea to introduce features into SVGDOM that require
>implementers to change/break the DOM.
>
>This problem could be overcome by introducing a new interface SVGString
>which derives from DOMString, and then have SVGTests use SVGString instead
>of DOMString.   Any chance of this change making it into the next release?
>
>S.
> 
>

Received on Wednesday, 2 August 2000 18:37:57 UTC