[concurrency-interest] Re: 'Future' definition

Patrick Moore pmoore@brocade.com
Tue, 10 Dec 2002 14:21:47 -0800


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2A09A.871B5B80
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Dawid --

I can see that we are going to have an interesting conversation :-) 

I don't find the discussion to which you refer in the concurrency archives.
If this happened in the jsr mailing list please send a link as it isn't in
the concurrency-interest archive.

... 
I don't see how being able to clear() is this huge barrier to being a first
class object. If some code needs the value not to change during an operation
it simply extracts the Future wrapped value. With regards to the
immutablity, you haven't explained why a mechanism, throwing
UnsupportedOperationException, that is used elsewhere for exactly this kind
of situation is inadequate here. Call Future volatile if you must but the
EDU package solves a real-world problem that this new package won't. 

In response to your comment:
"Why don't you instead write your own "result handler" or "cache object"
with set and clear 
methods invoked by callbacks, without necessarily implementing the Future
interface."

My answer is why? What is the significant difference? What is the contact
that I am violating? Why should I write my own when
EDU.oswego.cs.dl.util.concurrent.FutureResult is perfectly correct and
adequate. The Future concept works well and fits with the behavior.

If you think that having an immutable Future(Result) is important - I will
not disagree at all with you on that. The problem I have is that now I have
*less* functionality than I did before - which I will strongly disagree
about.

Like I indicated... not having it in there leaves me 3 choices none of them
very correct but each is 'better' than riting my own since I leverage
existing code.


-----Original Message-----
From: Dawid Kurzyniec [mailto:dawidk@mathcs.emory.edu]
Sent: Tuesday, December 10, 2002 1:19 PM
To: concurrency-interest@altair.cs.oswego.edu
Subject: Re: [concurrency-interest] Re: 'Future' definition


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
 
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@altair.cs.oswego.edu
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

------_=_NextPart_001_01C2A09A.871B5B80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [concurrency-interest] Re: 'Future' definition</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Dawid --</FONT>
</P>

<P><FONT SIZE=3D2>I can see that we are going to have an interesting =
conversation :-) </FONT>
</P>

<P><FONT SIZE=3D2>I don't find the discussion to which you refer in the =
concurrency archives. If this happened in the jsr mailing list please =
send a link as it isn't in the concurrency-interest archive.</FONT></P>

<P><FONT SIZE=3D2>... </FONT>
<BR><FONT SIZE=3D2>I don't see how being able to clear() is this huge =
barrier to being a first class object. If some code needs the value not =
to change during an operation it simply extracts the Future wrapped =
value. With regards to the immutablity, you haven't explained why a =
mechanism, throwing UnsupportedOperationException, that is used =
elsewhere for exactly this kind of situation is inadequate here. Call =
Future volatile if you must but the EDU package solves a real-world =
problem that this new package won't. </FONT></P>

<P><FONT SIZE=3D2>In response to your comment:</FONT>
<BR><FONT SIZE=3D2>&quot;Why don't you instead write your own =
&quot;result handler&quot; or &quot;cache object&quot; with set and =
clear </FONT>
<BR><FONT SIZE=3D2>methods invoked by callbacks, without necessarily =
implementing the Future interface.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>My answer is why? What is the significant difference? =
What is the contact that I am violating? Why should I write my own when =
EDU.oswego.cs.dl.util.concurrent.FutureResult is perfectly correct and =
adequate. The Future concept works well and fits with the =
behavior.</FONT></P>

<P><FONT SIZE=3D2>If you think that having an immutable Future(Result) =
is important - I will not disagree at all with you on that. The problem =
I have is that now I have *less* functionality than I did before - =
which I will strongly disagree about.</FONT></P>

<P><FONT SIZE=3D2>Like I indicated... not having it in there leaves me =
3 choices none of them very correct but each is 'better' than riting my =
own since I leverage existing code.</FONT></P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Dawid Kurzyniec [<A =
HREF=3D"mailto:dawidk@mathcs.emory.edu">mailto:dawidk@mathcs.emory.edu</=
A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, December 10, 2002 1:19 PM</FONT>
<BR><FONT SIZE=3D2>To: concurrency-interest@altair.cs.oswego.edu</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [concurrency-interest] Re: 'Future' =
definition</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2>Hello Patrick,</FONT>
</P>

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

<P><FONT SIZE=3D2>Dawid</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>Concurrency-interest mailing list</FONT>
<BR><FONT SIZE=3D2>Concurrency-interest@altair.cs.oswego.edu</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interes=
t" =
TARGET=3D"_blank">http://altair.cs.oswego.edu/mailman/listinfo/concurren=
cy-interest</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2A09A.871B5B80--