Name Patterns in Limpid

Background

The influence of Java on the W3C DOM is very clear in the patterns for names of nodes and their methods (functions). It is possible to deviate from standard practice (spelling intended) in Java, but normal use is along the following lines:

• Class and method names have the 'camel-back' form, eg:DocumentType rather than document-type, document_type or any other variation.
• Class names start with an upper-case character.
• Instance and method (function) names start with an upper-case character.

This has the nice side effect that an instance of a class can have a clear relationship to the class itself, eg nodeList as an instance of NodeList. Furthermore, if this discipline is followed, there is no problem remembering whether or not you have decided to name a class myClass or MyClass, or whether an instance is myInstance or MyInstance or whether one of its functions is getFirst() or GetFirst().

The JavaBean get/set concept and name pattern is in evidence. For Node, examples are getNodeType(), getChildNodes(), getFirstChild(), etc. These methods (functions) are part of the W3C DOM recommendation, and are adopted fully in Limpid. Set methods, such as setNodeType(), are much less common, because of the requirements of the DOM, but one example is NamedNodeMap::setNamedItem().

There is the occasional inconsistency in the recommendation, too. Examples are NodeList::item() and NameNodeMap::item(), where getItem() might have been expected. DocumentType is sometimes referred to as doctype (Java programmers will recall HashMap, but Hashtable); more serious is Element::getAttribute(...), while the class is Attr!

A specialisation of the get/set pattern relates to boolean values. When the getXXX() method returns a boolean, the name might be isXXX() or hasXXX(). Examples are Node::hasChildNodes() and Element::hasAttribute().

A final pattern that has not yet been fully implemented throughout Limpid is:

• Class members have names that end with an underscore, such as context_ to distinguish them from names of parameters or values local to a function.

Name Patterns in Limpid Classes

These follow the same form as in Java. The main groups are:

• Streams, including NodeStream, ListStream, SiblingStream, AncestorStream, XMLParser. Each of these with the single interface nextNode(), providing a succession of Node references.
• Processors, including Builder, XMLWriter, CollectionProcessor, Sizer, ValidationProcessor. Each has the single interface function: process(Node& node), with diverse outcomes: constructing nodes, collecting selected nodes, recording node sizes, validation against a DTD or Schema.
• DocumentProcessors, including Putter, Transformer, Mutator, Stepper, Reporter, ElementDropper, AttributeStripper, TexBuilder and Prototyper, each with the main interface function: processDocument(Document& sourceDocument).
• Parsers, including XMLParser, CSVParser, RJParser, SXFParser.
• Tests, including NameTest, TypeTest, PathTest, AndTest and OrTest. These share the single interface test(Node& node),providing a boolean result.

All of these classes have self-describing names and interfaces and, in combination, provide much of the power of Limpid.