Re: XML APIs

John Cowan <cowan@locke.ccil.org> writes:

> Stephen R. Savitzky wrote:
> 
> > I do not understand your point.  They certainly hold as far as I can tell;
> 
> Provided the tree doesn't get modified while traversing it.

Valid, but perhaps not as important as you seem to think.

> > Piling additional complication into the specification in order to ensure
> > that every node in the tree will continue to be visited no matter what gets
> > done between calls to "toNext", which I believe is what the last spec that
> > included iterators attempted to do, is WRONG, because it makes the simple
> > implementation impossible and because it becomes too complicated for a
> > programmer looking at the spec to guess how it's going to behave.
> 
> Well, I disagree with you.  If iterators are to be useful, they must
> be robust against changes to the structure being iterated over, or
> at the very least they must warn that the iterator is no longer valid,
> like the new Java 1.2 enumerators.

I think that this may be at the very core of our disagreement.  Iterators
_are_ useful, even with limitations.  My application, for example, treats
parse trees as immutable.  Requiring my implementation to account for their
potential mutability imposes a very large overhead that I am unwilling to
pay.  Similarly, I process documents by making a single pre-order traversal
of an input document, and constructing a corresponding output document.
Under these conditions I don't _want_ iterators to have to reconsider what's
happening in the parts of the tree I haven't visited.

An additional problem is that in garbage-collected languages there is no
good way to identify ``dead'' iterators, which no longer have to be
updated.  (Even in Java, which is soon to have ``weak'' references, it is
possible to have objects which are inaccessible but have not yet been
garbage collected.)  

It is possible that in _your_ applications, iterators have to be ``robust
against changes'' in order to be ``useful'' to you.  This is not one of _my_
requirements; I would be satisfied with a simple phrase to the effect that
``the behavior of an iterator under changes of document structure may be
undefined in some implementations.''

> > The API is designed to have an obvious model that looks
> > like a parse tree.  Any programmer, looking at that API, will ``see'' the
> > parse tree in her mind's eye and be able to make intuitive and accurate
> > predictions about how it will behave.
> 
> Indeed.  But soon after learning about live node lists, this model
> will have to be changed or her programs will be dreadfully erroneous.

Indeed.  That is _precisely_ my point.  It is this kind of surprise that
makes the specification erroneous.  ``Liveness'' has _extreme_ consequences
throughout the implementation; this makes it difficult, if not impossible,
to come up with a clean and efficient implementation.  A ``natural''
implementation under my definition _would_ be clean and efficient; in some
sense it's the ``greatest lower bound'' on possible implementations. 

> > I'm going to go a little further, and define ``natural model.''  The natural
> > model of an interface is a class in which all attributes are represented by
> > instance variables, and no other instance variables are present.
> 
> The trouble with such a "natural model" is that it's dead.  It works
> perfectly for values (which have no state, i.e. are immutable),

Excuse me.  Values _do_ have state; it's just that you can't _change_ that
state.  The reason live NodeList causes so much havoc is precisely that it
_appears_ to have state, but in fact requires extremely non-local operations
in order to perform according to spec.  This lack of locality
(i.e. lack of encapsulation, in OO terms) is what makes it incorrect.

> and for "dart boards" that react to whatever's posted to (thrown at?)
> them, but not for anything with any liveness.  A robot modeled by such a
> "natural model" would be more like a Barbie doll: poseable, but unable
> to move by itself.

Not so.  Not at all.  All I'm insisting on is that _if there are no other
active threads of control in the robot's computer_, that the values I put
into its joint positions be the same as the ones I get out after it has
stopped moving.

-- 
 Stephen R. Savitzky   Chief Software Scientist, Ricoh Silicon Valley, Inc., 
<steve@rsv.ricoh.com>                            California Research Center
 voice: 650.496.5710   fax: 650.854.8740    URL: http://rsv.ricoh.com/~steve/
  home: <steve@starport.com> URL: http://www.starport.com/people/steve/

Received on Tuesday, 3 November 1998 14:18:40 UTC