XOM API for Processing XML with Java

["Steve Loughran" <steve.loughran AT gmail.com>]

On 31/10/06, Christian Vest Hansen <karmazilla AT gmail.com> wrote:

> That's actually not specified according to the Javadoc:
> "Returns an iterator over the elements in this list in proper sequence."
> If you can do it with One Iterator to Return to Them All, then have fun.
> However, just creating a new Iterator instance is probably easier.
>
> >
> > That's precisely why I think what I am doing consistutes an abuse. :)
>
> Not as long as you can guarentee that the returned iterator is
> positioned so that it will return the first element in the collection
> (if any) upon the first call to next() ;)

and is thread safe w.r.t the other instance,. Right now I can't make
those guarantees, so I'm probably creating the maintenance problems of
tomorrow. At least this next generation of  problems come with unit
tests.

> > Good point. I could store a reference to myself in the constructor,
> > return that the first time and set it to null. Second time round:NPE.
>
> On the other hand, this *would* be abuse.
> First, having iterator() throw an exception is something I would file
> under "Bad surprises". It is not part of the interface, and is not
> even hintet as a posibility in the documentation.
> Second, NPE has a special meaning. At least in my mind. It means,
> directly translated: "You, the programmer, made a 'bad assumption',
> aka. bug, somewhere in your code. Now please be so kind and go fix
> it."

True, I should make it a java.lang.IllegalStateException. I was just
bemused by the idea of an access to a null pointer automatically
triggering the fault.

> What I'de do instead is just create new instances of some Iterator
> implementation in the iterator() method, and return this new instance.
> And then be more concerned with the object creation happening *inside*
> the foreach-loop ;)

But that still relies on me being able to clone the other iterator or
something.

Overall, I do think having iterables being iterators does constitute
trouble, and all the valuable consultation on my code reinforces it.
But isn't it cute to be able to have an xpath() method that returns an
iterable, without any stub classes getting in the way. [irony warning]
It's almost a use for generics. I think will view it as one of those
early abuses of the new language features, the same way adopted and
abused C++ generics when C++ 2.0 came out, until things like STL and
ATL came out to show us how it should be done properly.

Maybe I should clean up my code now, before the bad habit settle in,
with some bridge class which, if my crude generics experience doesnt
mislead me, comes out as :

class IteratorBridge<T> extends Iterable<T> {
Iterator<T> i;
public  IteratorBridge<T>(Iterator<T> i) {this.i=i;}
public Iterator<T>() {return i;}
}

Then  my xpath method would have to declare it returns an
Iterable<Node>, and it really returns a new IteratorBridge<Node>(new
NodeIterator(query(xpath,context)));

But he nice thing about returning making an iterator an iterable is
that it can be used outside a foreach loop with ease; I add another
explicit method call every time here.

-steve