little iterator problem

[abir]

Hi ,
How can I make something like
List<MyClass> list;///or any other Collection
Iterator<MyClass> it = list.iterator();
Iterator<MyClass> next = ++it;
i.e I need a clone of the next iterator (like the one we do in C++ )
can something like
Iterator<MyClass> next = it.close();
next.next(); can be done?
In that case how the client code will get back the value( again) ?
so to say, how can my algorithm work with two iterators ? or how to
get copy of an iterator from another (not from Collection)

thanks
abir

 

[Alexander.V.Kasatkin]

šIn that case how the client code will get back the value( again) ?
so to say, how can my algorithm work with two iterators ? or how to
get copy of an iterator from another (not from Collection)

Seems that you can't do this with an arbitrary collection.
But the List<?> interface provides the listIterator() method
which returns an instance of the ListIterator<?> object.
It supports bidirectional iteration.


BR, Alex

 

[abir]

Seems that you can't do this with an arbitrary collection.
But the List<?> interface provides the listIterator() method
which returns an instance of the ListIterator<?> object.
It supports bidirectional iteration.

BR, Alex

Is it possible to clone an iterator (not ListIterator ) ?
So that I can write ,
Iterator<MyClass> it = ...
Iterator<MyClass> nextIt = it.clone(); nextIt.next();
I need two iterators which jumps at different speed (like Floyd's
algorithm), and then need to compare iterators & values.

thanks
abir

 

[Mark Space]

Is it possible to clone an iterator (not ListIterator ) ?

It doesn't appear to be possible. It's a good idea, probably something
Java should support, but the current version does not.

I don't like the clone() interface myself, it's pretty sloppy. Something
like a factory method in Collection, or a class method in the Iterator
interface, would be a bit cleaner.

Iterator i2 = i.dupIter(); // or something

 

[Mark Space]

That hardly seems simpler than

Iterator<Foo> i2 = collection.iterator();

The problem that I see with the above is:

Iterator<Foo> i1 = collection.iterator();
Iterator<Foo> i2 = collection.iterator();

for( ; i1.hasNext(); )
{
Foo f = i1.next();
i2.next();
// do something
}

Having to manipulate i2 as well as i1 and keep them both in synch
doesn't seem to me like the cleanest idiom. It isn't clear that I can
always skip call "hasNext()" before calling next on any given iterator.
I've written custom iterators where hasNext() set up variables for the
call to next(). This was a mistake in my opinion, and I later corrected
it, but there's still a lot of variability when dealing with other
iterators of unknown quality.

Whereas

Iterator<Foo> i1 = collection.iterator();

for( ; i1.hasNext(); )
{
Foo f = i.next();
// do something
if( something )
{
// branch here
Iterator<Foo> i2 = i1.dupIter();
// process with i2 now
}
}

seems cleaner, especially if a large or variable number of copies of i2
could be created.

 

[Mark Space]

It isn't cleaner. You have ConcurrentModificationException issues if
both iterators operate at the same time. But I see what you want - you
somehow want to "branch" an iterator to pick up at the point where 'i1'
leaves off, correct? Then maybe return to i1 later. Is that it?

I assume that's what the OP is after, yes.

I'm a little dubious of the use case, but if I understand the
requirement correctly it seems like there shouldn't be too much trouble
coding up such a dupIter(), maybe using a custom List implementation to
support it, say, ForkableList<T>.

I can't think of any algorithms off the top of my head that need a
"forkable iterator" but I don't know every algorithm, either. I can see
it would be a useful thing in some cases. A method to duplicate an
iterator, at it's current point of iteration, might be hard to implement
in all cases for all iterators (which is why Sun doesn't include it in
the base API), but I can't think of an iterator right away where it
couldn't be done.

Problems with modification aside, it seems like a good general case of
iterators. Seems worth bugging Sun about it.

By now we're beginning to see ListIterator to be useful, but the OP has
rejected any use of ListIterator for some unknown reason. Otherwise one
might just use ArrayList, capture the index of the fork point, and start
a ListIterator at that index at need. Oh, well.

I assume he'd have to copy an arbitrary collection to a list, which is
O(n) and therefore unacceptable. Implementing new iterators for each
kind of list might be unfeasible, since he may not have control over
other parts of the program/spec/contract.

What I'm not sure of is why this particular algorithm is required. It
maybe best for the type of data being collected. At this point,
implementing one's own data structure and forgoing Collections might be
the only option.