On 16/01/17 11:02, Pavel Bucek wrote:
>
>>> .rx(CompletionStage.class)
>>>
>>> will work with whatever library the users will choose, from Jersey,
>>> some 3rd party library, etc
>>
>> Mine issue with this is that you usually dont want to do
>> rx(CompletionStage.class). You most likely want
>> rx(CompletionStage<List<String>>.class), which is not valid Java
>> syntax. And I must admit I don't like GenericType and I'll be always
>> trying to find an alternative which won't force that.
>
> this is most likely not correct, since rx(Class<T>) doesn't return T
> but RxInvoker<T> and then that shouldn't be an issue. (since RxInvoker
> does have get(Class<R>) and it would be defined to return T<R> I guess.
>
> Anyway, there is one issue. In mine proposal, rx(..) returns T ?
> extends RxInvoker, which allows invoker specific methods. Not saying
> it is a big deal and I don't really think that it will be widely used,
> but it is a difference.
Interesting, thanks for reminding about it. I'm not sure at the moment,
from one point of view, that can lead users to writing a less portable
Rx code, then from the other point of view, given how diverse Rx impls
can be, it can be hard to restrain all of them by RxInvoker alone...That
said RxInvoker looks very complete to me as far as Rx with HTTP is
concerned....
Sergey