why not both Future and CompletionHandler?

[Rémi Forax]

On 04/14/2011 05:38 PM, Alan Bateman wrote:
> Sangjin Lee wrote:
>> Yes, I think it can come very handy if you want to add some 
>> cross-cutting concerns in the completion handlers but allow the end 
>> users to interact with the result via Future.
>>
>> For example, suppose I build a framework/library for others using the 
>> async channels (HTTP app, ssh app, etc.). I want to allow my users 
>> freedom to choose between the "pull" (future) and the "push" 
>> (completion handler). However, *regardless* of what my end user 
>> choose to interact with the result, I want to be able to inject some 
>> concerns like logging, instrumenting, etc. in the form of a 
>> completion handler (can be completely internal to the framework).
>>
>> With the current APIs, if the user wants a future, the framework 
>> cannot use the completion handler and I would need to find another 
>> way to inject such logic. Or if I want to retain the completion 
>> handler for the framework, then I would need to create my own future 
>> objects to provide to the end users. Either approach is doable, but 
>> it would be so much easier if the NIO.2 APIs provide both mechanisms 
>> in a single method call. My 2 cents. Thanks!
> For high performance applications using completion handlers then we 
> don't want to future Future objects that won't be used. In your 
> framework/library then won't it return your own Future type anyway?
>
> -Alan.

Or if I want to use a completion handler but have also a way to cancel 
the operation.

Rémi