[concurrency-interest] Re: 'Future' definition

Dawid Kurzyniec dawidk@mathcs.emory.edu
Tue, 10 Dec 2002 16:19:26 -0500


On Tuesday 10 December 2002 01:25 pm, Patrick Moore wrote:
> Hi Doug -
>
> The decision about not having a clear() method in the Future interface
> would be more tolerable if it wasn't for the fact that such a method is
> missing (even protected) from FutureTask. Since set(null) is not the same
> as a clear(), this means that I have to:
>
> 1) reimplement all of FutureTask's functionality or
> 2) using reflection trickery ( Method/Field.setAccessable(true) ) in a
> FutureTask subclass or
> 3) Continue to use the EDU version...
>
> I would suggest that if it is perfectly permissible and useful to have the
> set(), setThrowable(), clear() methods in the interface but define it that
> implementors of the interface may throw UnsupportedOperationException.
> (There are plenty of examples of this in the Collections as well as
> Iterator does the same.) So FutureTask may have:
>
> (...)

Hello Patrick,

On the other side, I have been strongly arguing some time ago not only _not_ 
to include clear and set methods in the Future interface, but even to put 
immutability in the Future interface contract (this suggestion has been 
rejected). I see setters and clearers as a potential breach of encapsulation: 
anyone who has hands on your future may mess you up by changing the value or 
clearing it; also, you can no longer assume that once you have result from 
getResult(), it will stay the same for subsequent reads. So then you couldn't 
safely treat futures as first-class objects and pass them around. I was 
arguing that if you need resettable futures, you would be better off using 
callbacks instead. You may want to check out the archives to find more 
details. In the example you gave (the periodically refreshed cache), I don't 
think the future is the most appropriate _abstraction_ to use. Why don't you 
instead write your own "result handler" or "cache object" with set and clear 
methods invoked by callbacks, without neccesarily implementing the Future 
interface.

Dawid