river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: TaskManager progress
Date Thu, 22 Jul 2010 19:32:50 GMT
Greg Trasuk wrote:
> On Thu, 2010-07-22 at 14:46, Gregg Wonderly wrote:
> 
>>> Ok, didn't think of that, still using the old for loop.
>> I think the subtle issue that Peter was getting at though, is that Iterator has 
>> the "remove()" method which perhaps should not be a published behavior, since it

>> implies an API that is not currently in the design of the system.  I'm not that 
>> bothered by this in an internal API, but in some cases, you have to be careful, 
>> and perhaps pass a copy, as in
>>
>> 	new ArrayList<Task>( ... ).interator()
>>
>> just to make sure that your original collection is not compromised by other 
>> software.
>>
> 
> 'remove()' is an optional operation.  You can just take the original
> Iterator and wrap it inside an Iterator that delegate next()  and
> hasNext() to the original, but throws UnsupportedOperationException on
> everything else.
> 
> Matter of fact, I wouldn't be surprised if
> java.util.Collections.unmodifiableCollection(...) does pretty much that.

Yes, I just wanted to point at that if you had not controlled this issue in some 
way, it may come back to bite you.  Adding the "RuntimeException" into the mix, 
can be a good thing, but often, doing this after the fact is a bad thing because 
you then discover external users that are doing remove(), in a not so good way 
when the thread dies or otherwise starts behaving strange.

I would of preferred an interface such as

public interface MutableIterator<T> extends Iterator {
	public void remove();
}

had been defined.  We are learning more and more, the power of immutability, and 
  calling it out in the name space, for me, is a good thing.

Gregg Wonderly

Mime
View raw message