Hi Tinny,
OK. We are mostly back to what I originally proposed, keep both interfaces,
but have the original DOM interface delegate to the IDOM interface.
Just to make sure I am not diverging from what you would agree with please
let me know what you think of the following:
I added these methods:
/**
* Indicates that there is another user out there that depends upon the
node remaining
* in memory. Implementations can take advantage of this to know when
it is safe to
* release memory for a node.
*/
virtual void addRef() {}
/**
* Indicates that there is one less user out there that depends upon the
node
* remaining in memory. Implementations can take advantage of this to
know when
* it is safe to release memory for a node.
*/
virtual void removeRef() {}
/**
* Indicates that there are no more users that depend upon the node
* remaining in memory. Implementations can take advantage of this to
know
* that it is safe to release memory for a node.
*/
virtual void release() {}
to the following base classes (pre-rename names):
IDOM_DOMImplementation
IDOM_NamedNodeMap
IDOM_Node
IDOM_NodeIterator
IDOM_NodeList
IDOM_Range
IDOM_TreeWalker
Handles would automatically call addRef and removeRef, which implementations
can use to know when to call release. Those not using handles would have to
explicitly call release when they are done with a pointer if they are
concerned about memory growth.
Would it be preferable to have a single base class that collects these
methods, one that each of the above classes inherits from? Perhaps called
DOMResource. One problem I see is that there is no counterpart to such a
class in the DOM specification, but it does present a convenient way to
represent the concept of resource, and since those using raw pointers are
going to be involved managing resources, it could help.
Lenny
-----Original Message-----
From: Tinny Ng [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 06, 2002 1:00 PM
To: [EMAIL PROTECTED]
Subject: Re: Call for Vote: which one to be the Xerces-C++ public
supported W3C DOM interface
Lenny,
I prefer
> DOM_Element element = ...;
> DOM_Node first = element.getFirstChild();
which complies to our fundamental C++ concepts where '->' is for pointer,
and '.' is for object.
The declaration "DOM_Element element" is declaring an object. From users
perspective, they don't really know it's smarter pointer underneath. If we
ask users to do this:
> DOM_Element element = ...;
> DOM_Node first = element->getFirstChild();
then it deviates from the fundamental C++ concepts, and is very confusing to
those C++ beginners.
Tinny
----- Original Message -----
From: "Lenny Hoffman" <[EMAIL PROTECTED]>
To: "Tinny Ng" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, May 06, 2002 11:11 AM
Subject: RE: Call for Vote: which one to be the Xerces-C++ public supported
W3C DOM interface
> Hi Tinny,
>
> We have a choice here in how we implement our handles: keep backwards
> capability with the original DOM interfaces at the cost of maintaining a
> full dual interface, or sacrifice backwards compatibility with the
original
> DOM, but gain simplified maintenance, and possibly an easier interface to
> understand. Let me explain --
>
> I had originally kept the DOM_ interfaces, but had them delegate to the
IDOM
> for anything that they did (this gives us the greatest backwards
> compatibility with the original DOM). But in the recent discussion I
> thought you made the point that having such duplication of interfaces
> represented increased maintenance, so I proposed changing the DOM_
> interfaces so that they are smart pointers, thus eliminating method
> duplication (this loses backwards compatibility with the original DOM).
For
> example, instead of:
>
> DOM_Element element = ...;
> DOM_Node first = element.getFirstChild();
>
> where there is both a DOM_Element::getFirstChild and an
> DOMElement::getFirstChild, you would have:
>
> DOM_Element element = ...;
> DOM_Node first = element->getFirstChild();
>
> where there is only DOMElement::getFirstChild. Having the DOM_ interfaces
> be simple smart pointers that delegate to methods using a single
> overloaded -> operator instead of multiple methods for each method on a
node
> interface. In fact in my prototype I was able to do in a single header
file
> what was done in 14. With main development going forward on the renamed
> IDOM interfaces, this approach offers the advantage of quick and easy
> turnaround on adding handle support to new interfaces.
>
> The smart pointer approach should also be easier to explain in the
> programmers guide. For example it can be explained that when wishing to
> have automated "in use" indication assign returned nodes to handles:
>
> {
> DOM_Element element = ...;
> DOM_Node node = ...;
> element->removeChild(node);
> ...
> } // release on removed child called here automatically
>
> Or if wishing to avoid handles assign to pointers and explicitly call
> release:
>
> {
> DOMElement* element = ...;
> DOMNode* node = ...;
> element->removeChild(node);
> ...
> node->release();
> }
>
> However release is called on a node, either by an implementation reference
> counting with the help of handles or explicitly, it indicates to the
> implementation that there are no longer any clients to the node and that
it
> resources could be released or recycled. The memory growth fix I came up
> with for the IDOM, for example, would recycle memory for the node and its
> strings upon a call to release if that node were no longer part of the
> document.
>
> Since you and others were willing to forgo the original DOM altogether, I
> got the impression that backwards compatibility with it was not too
> important. As you can see, the methods accessed via the smart
pointer's ->
> operator are really on the new IDOM interfaces and thus are not backwards
> compatible with the original DOM.
>
> Although I lean toward the simpler smart pointer approach, I can go either
> way, just let me know.
>
> Lenny
>
> -----Original Message-----
> From: Tinny Ng [mailto:[EMAIL PROTECTED]]
> Sent: Monday, May 06, 2002 9:27 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Call for Vote: which one to be the Xerces-C++ public
> supported W3C DOM interface
>
>
> >
> > BTW, the handles are no longer backward compatible with the original
DOM_
> > classes, and thus should follow a different naming convention. Since
you
> > are renaming the IDOM_* classes to DOM*, perhaps the handles could be
> named
> > DOM*_h. This is just my initial thought, you may have a better idea.
> >
>
> As indicated in my other post, I don't really want to rename the old DOM
> interface. In fact how incompatible are the handles going to be? Except
> the removal of "XML_DECL", I would prefer to keep compatibility as much as
> possible in the old DOM interface after the patch.....
>
> Tinny
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
