On 26/08/11 17:25, Marek Potociar wrote:
>
>
> On 08/26/2011 06:19 PM, Markus KARG wrote:
>>> Markus, Sergey: I have reintroduced the target.request(), you didn't
>>> like. However I tried to do it in a way that does
>>> not bring any extra method into the invocation chain. Instead of:
>>>
>>> client.target().accept("text/plain").get();
>>>
>>> You can now write:
>>>
>>> client.target().request("text/plain").get();
>>
>> Actually I do not see why it is necessary to *rename* the method. Obviously it still is used to pass in the accept header, so why not still name it accept, independent of what it actually does or produce?
>
> It was not just a pure rename... This method provides the cleaner shift in the flow context and does not require Target
> to implement headers builder interface. I know accept() does not require implementation of any interface either, as
> such. But once we have accept(), why don't we have header(), allows() and other header-related mutators? And then we're
> back to the SoC issue pointed out by Bill and Santiago.
Content-Type and Accept are two fundamental headers - having no explicit
accept() is -1
Sergey
>
> Marek
>
>>
>>> In the fluent interface I prefer async().put() over putAsync() or
>>> asyncPut().
>>
>> Me, too.
>>
>> Regards
>>
>>
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com