CompletionHandler should take the channel too

[Alan Bateman]

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?

-Alan.