commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Schapitz <>
Subject Re: [collections] suggested extensions to package oacc.iterator
Date Sat, 29 Apr 2006 20:32:12 GMT
Sorry for getting back that late, but I finally found the time to
add a sequence of patches to bugzilla for this:

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!)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message