- From: Ray Whitmer <ray@imall.com>
- Date: Fri, 11 Dec 1998 10:58:35 -0700
- To: "Andrew M. Kuchling" <akuchlin@cnri.reston.va.us>
- CC: www-dom@w3.org, xml-sig@python.org
Andrew M. Kuchling wrote: > [CC'ed to xml-sig@python.org and www-dom@w3.org; followups to > www-dom@w3.org] > > With reference to the Python DOM implementation, someone has raised > the question of testing the equality of nodes. I don't think there's > anything in the DOM Recommendation that discusses this question, > possibly because the issue doesn't raise its head in Java. I don't know Python, but very object in Java has an equals method to signify deeper comparison than "==", for example, String.equals tells whether the contents of two strings are identical. > * Should Element instances also compare their attributes? > I would say 'yes', since the attributes are really associated with the > Element node. > > * If the two nodes have identical type and value, should the > comparison be recursive, comparing the children of the nodes. The == > operator would then be comparing entire subtrees rooted at node1 and > node2. I'm not certain if this is the best choice for the meaning of > ==, but see no clear reason to choose recursive vs. non-recursive ==. > Any suggestions? For my own uses on both the client and server (in Java, not Python), the full/deep comparison is the most useful and as such I implemented it in a private API extension extremely efficiently. A full/deep comparison is very useful in many situations, and can be implemented much more efficiently than forcing the user to check equality one attribute or recursive child at a time (with acceptable tradeoffs in other parts of the implementation). But I would recommend NOT using the built-in Python operator, just as I am not using the built-in equals method in Java, until it has been defined in the standard how this should be implemented. Otherwise, users of your implementation will not be interoperable with users of other implementations, and also possibly not interoperable with the standard definition if one is ever officially formulated. Instead, define the operator to raise an exception, if Python has one, and if you need an equality check, write one in a private API with your own name on it so it will be clear to users that by using your method, they will be sacrificing portability, in exchange for a concise, permanent definition of its behavior. The problem in Python is much bigger -- possibly rendering my advice irrelevant -- since no official DOM API binding has been released for that language in the first place. I am just following how I would tell someone to deal with the equals function in Java where users will expect portability between implementations. I don't know Python, so it is also possible that Python may impose more rigidity on the requirements of == (than Java does on equals), making it possible to know what the standard implementation should be, but your raising the question would seem to indicate that it does not. Ray Whitmer
Received on Friday, 11 December 1998 12:59:14 UTC