I would like to focus on some of the implications of the Java DOM interfaces that return nodes. There are two groups: Specific Node Types, including
and Non-Specific Types, including:
When Node is specified as a return value, this is an exercise in polymorphism. The returned type a node, but it is also a specific type of node (Element, Text, etc). In applying the Java interfaces to C++, the return type to be either a pointer or a reference. Given that we prefer to avoid pointers, Limpid must therefore always return a reference. Bearing in mind the limitations on returning a reference, this is a safe approach because the value is being returned as a result of querying part of a document that is currently .
Although it is possible to return a value when a particular type of node is specified in the interface, I have chosen to return a from (say) Document::getDocumentElement(). Therefore assume that Limpid returns a node by .
DOMString, like any other class, has baggage and occupies memory. For this reason, I decided not to include DOMString instances in NodeContent. Some nodes have no special name. When, for example, a Text node is queried using getNodeName(), the returned value is a DOMString equivalent to "#text". This DOMString is extracted from a static character array by using the NodeType of the node.
Other nodes, such as Element and Attribute, have a node name stored in the NodeContent. In such cases, the character content of the NodeContent is stored as a null-terminated array of Char. When getNodeName() is invoked on the node, it returns the name as a DOMString. This is done quite automatically by a conversion constructor for DOMString.
All this detail is given to explain that there are no DOMStrings stored in the DOM. Therefore, given the previous discussion, the DOMString returned must be as a DOMString, and not as a DOMString&
Node parameters are specified as Node. Examples are:
As explained above, this is to support polymorphism. For this reason, all Node parameters in Limpid are passed as . This means the slight inconvenience, in hand coding, of having to define a node before it can be used:
void doLittle() {
Element parent("parent");
Element child("child");
parent.appendChild(child);
}
This inconvenience can be avoided by making the parameter for appendChild():
Element::appendChild(const Node& child);
Taking this approach, however, leads to practical and conceptual problems. It is, for example, reasonable to copy or append a node, or does violate the concept of constness? I have not yet made up my mind on this and similar problems but, if I do decide to go ahead with it and change the constness of the parameters for many of the internal functions, we can chain functions more liberally, eg:
void doLittle() {
Element parent("parent");
parent.appendChild(Element("child"));
}
Actually, this is a very general question throughout the Limpid package, as it applies to classes as diverse as streams, tests, XPath expressions and XSLT templates: Is it valid to copy a object?
Consistent with the passing in of nodes as references, DOMStrings are also passed as references, although in this case they are references.
There is no conceptual difficulty here, however, because a copy of a DOMString (which is simply a subclass of std::basic_string) is a fully independent copy, with shared content.
Many W3C interfaces allow the return of a value. Examples are:
Given that Limpid returns references, it cannot return null. Instead, it returns a reference to a static fail or default class instance, eg
Now, each of the DOM classes, Nodes, NodeList and NamedNodeMap, has a function:
Instead of querying a result for null, therefore, it is queried for validity:
The implementation of isValid() on the Node classes is very efficient, and relies on comparison of the node content with that of a specific static node type (failNode, failElement, etc).