- From: Don Park <donpark@quake.net>
- Date: Mon, 17 Aug 1998 21:21:43 -0700
- To: <www-dom@w3.org>
Claude, >>> It is impossible to implement Node.append/insertChild() etc. without >>> casting the Node argument to a known implementation. Otherwise, >>> how would you set the parent and next/previousSibling attributes >>> of the new child? Casting is slow (in Java) and it assumes a homogeneous >>> implementation. >> >>It is a simple virtual function. The implementation supplies the >>functionality, and the base class provides the API -- no expensive upcasting >>involved at all. OO languages would be in big trouble if you had to upcast >>every time you wanted to implement this type of a function. > >Hmmm, according to the latest spec Node.next/previousSibling are read-only. >How do you set these without casting to an implementation that has >set methods for these attributes if there are none in the interface ? > >I think maybe you thought there was Node.setNext/PreviousSibling() >methods defined somewhere. This, as I understand, was a typo in the old spec. >If not, then the latest spec isn't quite fully cooked. Suppose we had these methods in the DOM spec and you were to write following code: Node somenode = // get it from somewhere; somenode.setNextSibling(anothernode); somenode.setPreviousSibling(yetanothernode); somenode.setParentNode(somecontainernode); What are you expecting the setNextSibling method invokation to accomplish? Is it some variation of insertBefore or simple value assignment? Are you expecting the parent to change if somenode is not contained in the same node as anothernode? Are you expecting somenode's internal state to be valid across all three calls? Don Park
Received on Tuesday, 18 August 1998 00:30:36 UTC