[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-nio-dev
Subject:    CompletionHandler should take the channel too
From:       forax () univ-mlv ! fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date:       2009-05-12 19:02:53
Message-ID: 4A09C7DD.7030301 () univ-mlv ! fr
[Download RAW message or body]

Alan Bateman a ?crit :
> R?mi Forax wrote:
>> Alan Bateman a ?crit :
>>> R?mi Forax wrote:
>>>> :
>>>> I don't see why I have to create an ephemeral object to store a 
>>>> channel and a buffer
>>>> if the implementation already have this information but don't 
>>>> export it.
>>> I don't think we can predict all the context that the handler will 
>>> require when consuming the result. For some cases it may only be the 
>>> channel and the buffer (or buffers). In other cases it will be the 
>>> SSLSession or other session information. For non read/write methods 
>>> may be the channel and something else.
>> You probably misunderstand me, I haven't say that we should remove 
>> the attachment but
>> advocate for adding a parameter to all methods of the completion 
>> handler to give access to the channel.
>>
>> I can't see a scenario where the channel is not needed. Adding this 
>> parameter will free the attachment
>> that can be used for something else, the buffer, the SSLSession, etc.
> R?mi - just coming back to this from a few weeks ago. Clearly adding 
> another type parameter would the make this painful. Another approach 
> is not introduce a third type parameter but to instead pass it as 
> AsynchronousChannel, ie:
>  void completed(AsynchronousChannel channel, V result, A attachment)
> For the stateless case where you are using the attachment then it 
> would mean casting channel if needed. That would be consistent with 
> SelectionKey but isn't making full use of the language. Could you live 
> with that?

Yes.
Even if I think that another type parameter will not be painful.

Let me try to convince you.
Currently, Eclipse and Idea (I haven't tested with Netbeans)
are able to infer type argument.

By example using a read on an AsyncSocketChannel,
AsyncSocketChannel, channel=...
channel.read(buffer, null, new CompletionHandler
                                           here I hit Ctrl Space ----^

the IDE will complete :
channel.read(buffer, null, new CompletionHandler<Integer, 
AsyncSocketChannel, Null>() {
  public void completed(Integer result, AsyncSocketChannel channel, 
Null  notUsed) {
    ...
  }
   ...
});

Note that the return type and the type of channel appear in the signature of
the method read.
This is not the case of the type of the attachment.
So if you think that having three types parameters is more complex than 
having
only two, the type parameter to remove is the type of the attachment,
not the type of the channel.

>
> -Alan.

regards,
R?mi


[prev in list] [next in list] [prev in thread] [next in thread]