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]
