W3C home > Mailing lists > Public > www-dom@w3.org > July to September 1998

Re: Anybody for a server-DOM spec -> transferring nodes and listener model.

From: Don Park <donpark@quake.net>
Date: Mon, 17 Aug 1998 21:21:43 -0700
Message-ID: <002401bdca5f$b91c85c0$2ee044c6@arcot-main>
To: <www-dom@w3.org>

>>> 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
>>> implementation.
>>It is a simple virtual function.  The implementation supplies the
>>functionality, and the base class provides the API -- no expensive
>>involved at all.  OO languages would be in big trouble if you had to
>>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
>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

Node somenode = // get it from somewhere;

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

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:04 UTC