Hmmm, yes you are right. Concurrent modifications will cause problems. The remove
method on the looping iterator can be handled however (re-check if size == 0) and set
the flag.
Stephen
from:Jeff Varszegi [EMAIL PROTECTED]
I don't see how to implement this without being horribly
This was my take on it:
Since it uses the iterator provided by the collection, I
felt it would be wasteful to try to provide any greater
protection than that already provided by the collection's
own iterator (other than the stated benefit of allowing one
to continually loop over the collection).
- Original Message -
From: Jeff Varszegi [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Thursday, November 21, 2002 10:38 PM
Subject: Re: [collections] LoopingIterator
I agree with you about the protection. It can be a snapshot view
I don't see how to implement this without being horribly wasteful (checking every
value in the
collection backing the Iterator every time something is returned, getting a new
Iterator every
time through the loop, etc.). The thing is, you can't even depend on the
implementation of
hashCode()
Jonathan,
I was going to include your files in the CVS. However, I discovered that
they do not cope with the situation where the collection being wrapped is
altered. ie. hasNext() always returns the initially cached value, even if
the list is clear()ed or it.remove() is called. Can you sort this?
From: Jonathan Carlson [EMAIL PROTECTED]
I can add a remove method and test cases unless it's easier
for you to just add it. I think it would just use the
remove method on the Collection. If the iterator returned
by the Collection implementer doesn't support it then this
won't either.
If
It is attached with updated unit tests. It was so easy
that I'm surprised I didn't implement the remove() in the
first place.
Thanks!
Jonathan Carlson
Minneapolis, Minnesota
--- Stephen Colebourne [EMAIL PROTECTED] wrote:
From: Jonathan Carlson [EMAIL PROTECTED]
I can add a remove method
I'm very sorry to have taken so long to reply. I don't
check this box very often and I am deep into development so
checking it even less. I'll check back tomorrow for a
reply.
I can add a remove method and test cases unless it's easier
for you to just add it. I think it would just use the
Oops, I meant to say:
I think it [the remove method] would need to use the remove
method on the iterator returned by the Collection.
Jonathan
--- Jonathan Carlson [EMAIL PROTECTED] wrote:
I'm very sorry to have taken so long to reply. I don't
check this box very often and I am deep into
On Friday 18 October 2002 06:45 pm, Stephen Colebourne wrote:
[Jonathan, I have sent back to commons-dev mailing list which is the
appropriate place for design/code discussions.]
I took a quick look, and I believe that the code in the zip will work.
However, my main concern is why this would
[Jonathan, I have sent back to commons-dev mailing list which is the
appropriate place for design/code discussions.]
I took a quick look, and I believe that the code in the zip will work.
However, my main concern is why this would be needed. Is there a use case
for an iterator that never ends?
I
11 matches
Mail list logo
