W3C home > Mailing lists > Public > www-dom@w3.org > April to June 1998

Re: Hello and NodeIterator Revisited

From: Don Park <donpark@quake.net>
Date: Mon, 4 May 1998 06:17:41 -0700
Message-ID: <005901bd775f$07be6a80$2ee044c6@arcot-main>
To: <www-dom@w3.org>

>on top of existing structures. So differences in efficiency depending on
>the operations and the software you're using should be expected. This is
>the price to pay for having a common API.

The problem is that the current design directly causes faulty implementation
in Java.  One specific interface I am concerned about is NodeIterator.
Latest change made it impossible to implement it without causing unused
NodeIterators to pile up.  The choice is to either change the API again to
relieve the need to keep track of NodeIterators from Node or add 'release'
method to NodeIterator.

>Like what? If ECMAScript provides anything that other programming
>language doesn't and that makes the DOM API unusable with these other
>languages please name it.

ECMAScript is a scripting language which differs greatly from general
languages in terms of target audience and intended use.  If DOM is intended
to be easy to use, I would like to see DOM API designed specifically
designed for scripting languages so that the script writers will not have to
know what an iterator is.  Most script writers think of a collection as an
array and not as an object to invoke methods on.  They will find it weird
that they can't just write:

for (int i = 0; i < node.length; i++)

Following is just unnatural to script crowd:

if (node.hasChildNodes()) {
    var iter = node.getChildNodes();
    var child;
    while ((child = iter.toNextNode()) != null)

>> The fact that the Java
>> interface files that came with the latest spec could not even be compiled
>> filled me with even more despair.
>This is merely to be considered as a bug.

Some would say it is equivalent to checking in code without compiling it.

>> I can't handle the problems in Java unless
>> I do some deep Java Voodoo magic (i.e. bytecode modification during
>> runtime).
>Really? like what problem?

Latest version of SAXDOM will implement the latest spec faithfully but will
result in accumulation of NodeIterators.  This is not really a problem on
the client-side but it is a major weakness on the server-side where
thousands of DOM could be in memory and being iterated every whichway on
every HTTP request.

At this point, I have only two change requests to DOM WG:

1. Please add 'release' method to NodeIterator.
2. Please move indexing operations from NodeIterator to Node.


Don Park
Received on Monday, 4 May 1998 09:24:45 UTC

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