Re: Hello and NodeIterator Revisited

"Don Park" <donpark@quake.net> writes:

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

Urk, I'm scared by the prospect of memory mgmt issues perculating up
into the DOM API.  Is it really impossible to implement it without
unused NoteIterators piling up?  Is it also really neccesarry to keep
track of NodeIterators in the Node?  I think that keeping that state
in the Node is kinda asking for trouble anyways.  It greatly
complicates the behavior of the Node, and makes it difficult for me to
create my own Node classes because now I have to deal with the
Iterator implementations of each DOM implementation since they are
tied to the Node, and that interface has been left up to the
implementor.  Am I making sense here?  I can give a more detailed
explanation of my concerns if I hadn't made them clear yet.

I think that Itertors should maintain as little state as possible, and
that that state should be maintained in one place.  You certainly
don't want to spread the state of an Iterator across multiple
classes.  The only thing that I see making this difficult is the
deletion of the current object.

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

It the Iterator even neccesarry at the "core" level of the API, and
should it not be something that is left to specific language mappings?
Are we even talking about doing specific language mappings?

Do we need to come up with a tree/set traversal mechanism that works
across all the languages, or can we leave tree/set traversal up to a
standard language mapping?  What is the W3C DOM WG's feelings on this?
I'm personally unconvinced the this Iterator stuff has any reason to
be in the "core" level.  We need our data structures to be isomorphic
between languages of implementation at the interface level.  We do not
need the traversal of them to be the same.  If I'm in Lisp why can't I
work with my DOM hiearchy as a set of lists?  If ObjC why not Arrays
with Enumerators?  As long as I can map my object hiearchy from Lisp
to C I'm fine.  Let's not straightjacket our developers.

> 1. Please add 'release' method to NodeIterator.

Memory/Storage Mgmt. in this API would be an incredible mistake.

> 2. Please move indexing operations from NodeIterator to Node.

What do you mean by indexing routines?

Received on Monday, 4 May 1998 12:01:06 UTC