- From: Mike Champion <mcc@arbortext.com>
- Date: Thu, 30 Apr 1998 16:14:23 -0400
- To: "Don Park" <donpark@quake.net>, "www-dom" <www-dom@w3.org>
At 03:37 PM 4/30/98 -0400, Don Park wrote: >Hello there. > >I would like to point out some of the problems of the NodeIterator design. > >1. Mixing iteration operation with indexing operation is not a good. It is >confusing as well as burdening the implementors unnecessarily. Could you elaborate please? At one time, we had a NodeList class for "collection semantics", but by adding only a few additional methods to NodeIterator we got the same functionality. We realize that this is unconventional, but it seems to minimize the number of classes at a minimal cost. If there are arguments against this that we haven't already considered, I for one would listen. >2. Implementing the 'between' concept of position is elegant but makes >efficient implementation in Java very hard if not impossible. Due to 'live' >aspect of iterators, each iterator has to be attached to the 'link' between >two siblings. Cost of object instantiation is heavy in Java. Part of the reason for doing this was to emulate that familiar behavior of the java.util.Enumeration interface. We've extended the functionality, certainly, but not the fundamental concept. Again, I'd be glad to hear in more detail your argument that this would make efficient implementation difficult, and would entertain any better idea. The "old" way (having iterators point to Nodes) would have caused us to have to define all sorts of ad-hoc behavior if the "current" node was deleted, or modified, or moved, or a new node inserted before or after it, etc. > >3. NodeIterator should have a 'release' method to make it possible for the >target node to keep track of active iterators. C++ has destructor, Java's >finalize is less than useless. We're going to add a technical discussion of our philosophy on this general issue; basically, we don't want the DOM to have to expose memory management functions. This may become necessary in some languages/implementations, but not in the general case. Again, if the "tree" needs to keep track of iterators rather than the iterators simply keeping track of where they are in the tree, I could see your point, but I'd have to be convinced ... > >4. Using NodeIterator to iterate an element's Attribute is not wise since >most of the Node methods do not make sense if Attribute interface extends >Node interface. Sorry, I don't follow. Could you re-state this? >But then I would prefer to have the API settled >down more than anything. So would we all, let me assure you! But an API such as the DOM must meet NUMEROUS constraints, and finding our way through all of them has been rather difficult. It's very important to get this "right" before it is proposed to the W3C, and we have benefitted greatly from the feedback you all have provided. Thanks, Mike Champion
Received on Thursday, 30 April 1998 16:17:41 UTC