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

Claude Zervas wrote:

> 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.

No.  I was arguing that the primary target of an OO operation does not need to
be upcasting, but I didn't read carefully that the example you gave was an
argument to a method, not the primary object of the operation, which does indeed
require upcasting.

I don't consider it a problem.  I work in Java every day.  The price for
occasional upcasting (only when Nodes are passed as arguments to another node's
method in the DOM API) is not bad, and there are a variety of other common Java
cases which require it (such as use of Hashtables, Vectors, or implementation of
equals()).  I can do and publish a simple benchmark to demonstrate this if you
like.  The efficiencies gained in the implementation that would not be possible
if every implementation detail were set in concrete easily outweigh the single
upcast required in this case.  But, then, I am writing a DOM for extremely large
documents stored in databases, so I need the type of freedom the DOM API gives
me.

As I stated before, if your alternative suggestion is to eliminate every freedom
of the implementation underneath by dictating every detail, and exposing every
primative so that the user is free to create inconsistent states that do not map
well onto powerful engines, then I oppose that strongly, whatever the setting
the DOM is intended for.

My own implementation does not store previous/nest sibling pointers at all, and
cannot represent the invalid states that could be created if the user were free
to set these in inconsistent ways, nor could I produce as efficient an
implementation if the user were free to do this.  My implementation uses a child
alias's knowledge of its position in the parent's child list to return the
previous or next sibling when it is requested.

The fully-linked direct representation of the DOM previous/next pointers is not
powerful enough for my server or client uses.

Ray Whitmer
ray@imall.com

Received on Tuesday, 18 August 1998 12:06:03 UTC