Sorry for getting back that late, but I finally found the time to
add a sequence of patches to bugzilla for this:
http://issues.apache.org/bugzilla/show_bug.cgi?id=39449
Stephen Colebourne schrieb:
Looking for a way, to turn any existing iterator into one,
that can be exercised repeatedly, I stumbled upon the classes/if's
ResettableIterator, AbstractIteratorDecorator, and ListIteratorWrapper,
but didn't actually found an elegant solution for this. Obviously, the
simplest option to include something like this into collections, was to
turn ListIteratorWrapper into a ResettableIterator by implementing the
reset() method.
I'd welcome an patch for this with tests.
.. added in first.patch
1.)
A derivation of AbstractIteratorDecorator, with the only function to
record the returned elements,
as they are traversed - candidate name: CachedIterator or
CachedIteratorDecorator.
This Decorator would use a List as cache, which could either be
injected, or created automatically;
This sounds no different to ListIteratorWrapper, or
IteratorUtils.toList(). IMHO, [collections] is probably over
abstracted now.
in a package with basic implemtations like this, I wouldn't mind a
decent amount of abstractness
2.)
An Iterator, that wraps a list similar the manor, ArrayIterator wraps
access
to an array, with the possible extension, that reset() and add() would
be supported too.
Why not just call iterator() on the List object? Perhaps you mean a
ResettableIteratorWrapper, which could be useful.
.. the latter. Added as ResettableListIteratorWrapper, also in
first.patch. But I'm not exactly happy with the name. But then, I'm no
native speaker?
3.) Combining the two into ResettableCachedIterator (involves using
ChainedIterator to do the trick)
I'm suggesting to use the infix 'Cached' here, because there is the
possibility of a completely different implementation of a decorator
allowing resettability: by passing a factory, that is reproducing the
underlying iterator on reset, if necessary; The difference is obvious:
the cached approach is guaranteed to reproduce the sequence of elements
exactly, the factory appraoch is not;
This is probably best achieved as a patch to ListIteratorWrapper.
4.) Retrofitting ListIteratorWrapper, to use 1.) and 2.)
Changing a superclass is a binary incompatible change, so we couldn't
do that.
As of Java Language Spec Chap 13.4: not so. Changing the inheritance
will only affect binary compatibility, if you are dropping members or
reducing their visibility, which will not happen when wedging an
additional class into the tree.
5.) Writing a Decorator, that converts a ResettableIterator into a
LoopingIterator
Could be done but probably of limited value.
I dropped 3.) to 4.), mostly because I'm already wayward from my
original goals, but also because one of some of the experiments included
in second.patch.
In there is ResettableListIteratorDecorator which does, what actually I
intended with 4.) turning any Iterator into an Resettable(List)Iterator.
Thus it could be a binary compatible replacement for
ListIteratorWrapper, if it wasn't semantically different, in that it is
actually supporting the optional operations in a limited manner.
The other two provide total different aproaches:
- ResettableIteratorDecorator uses a Factory, that should simply
reproduce the iterator on reset()
- RewindingDecorator rewinds a ListeIterator using previous()
The former might be interesting for wrapping JdbcQuerys, especially if
you in fact want to see changes, that appeared in the db between passes,
the latter is a bit over the top.
The reason for my interest in resettable iterators is the
CartesianIterator in third.patch.
Names: I'm a bit uneasy with the suffix *Wrapper because:
- the way we use it here seems to indicate, that we wrap ListIterator or
ResettableListIterator, while we are actually Wrapping an Iterator or
List respectively.
- The developer guide of commons actually states, that the class names
should be suffixed with the collection types.
Frankly, I'm a bit at a loss there.
If the commiters would shoot out with a vote, which of those classes are
likely to be committed, I would start integrating the corresponding
constructors into IteratorUtils and the Test into iterator.TestAll (yes,
there are tests in the patches!)
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
