Re: cloning Iterators?
On Feb 18, 10:37 am, Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at>
wrote:
Owen Jacobson <angrybald...@gmail.com> wrote:
On Feb 18, 9:46 am, Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at> wrote:
I can't think of any reason, how this cloning could ever be non-
trivial to implement for any type of collection/iterator, but
perhaps someone else knows of some ferro concrete strong reasons
why this could be a bad idea, and cares to let me know?
As it stands, I can write (and have written) iterators over some input
source such as a stream or ResultSet. Forcing all Iterators to be
Clonable would make them unusable for that (and I'd basically end up
writing my own Iterator interface, sans Clonable).
Thanks! That's exactly the ferro concrete reason, that didn't occur
to me. I didn't think of iterable ressources, that are consumed during
iteration.
If anything was to be done, it would be subclassing Iterator to a
CloneableIterator, for which the standard collections could be
retrofitted to actually return that, but this is another story...
It should be possible to express the union using type bounds, which
would be marginally more flexible than requiring a specific joint
interface ClonableInterator:
import java.util.Iterator;
public class JointType {
public <E, T extends Iterator<E> & Cloneable> void
takesCloneableIterator (T iterator) {
T copy = iterator.clone ();
/* use copy and original */
}
}
However, this doesn't work for two reasons:
- you need to cast the return from clone.
- the Cloneable interface doesn't actually declare the clone()
method.
To use cloneable you actually need a reference of a type implementing
Cloneable that has a public clone method, rather than of Cloneable.