We were talking about iterator.next() modifying the backing collection, which obviously violates the contract of .next().
I may have missed something, but couldn’t the actual creation of the iterator (ie. collection.iterator()) actually strip out any dead objects? Then the iterator just behaves normally.
Although I’d be slightly worried that the reported size (via .size()) of a collection and the amount of objects you iterate over could not match up. That might trip you up if you’re not careful (say, allocating an array and then iterating to fill it up). I don’t think you can get a 100% safe collection with the iterator trick, but it’s probably close enough that the bugs would be rare if you’re aware of it.
Doh. I missed that entirely.
That’s exactly how it is done. One iterator wrapping another.
[quote=“Orangy Tang,post:42,topic:40000”]
It isn’t the aim to create a general purpose collection/iterator pair. The purpose is the write a specialized piece of code that solves a specific problem, and should be regarded an implementation detail, not part of a (defendable) public API.
I really wonder what makes this trivial problem so confusing.
Aye he did, except he did it clearly in just a few words without any assumptions, egotism, or argumentativeness. Like a breath of fresh air!
The problem had long been solved, without assumptions, egotism or argumentativeness, before the part about weak references.
You guys are great. So much smart and fun in one thread.
So much complexity for such a trivial thing :emo:
Cas 
What are you talking about? Just last night I got 90% done scoping out my AbstractEntityLifeCycleCollectionFactory. I just need to connect a concrete implementation thereof to one of my XMLConfigurationEnterprise Beans and I should be 60% of the way to being 30% done!
Although the discussion has touched on a lot of different topics and whatnot, an iterator that removes dead entities in the background during iteration doesn’t strike me as all that complex to write or to use.