I appreciate that my clarifications must've been plainly awful as
yourself and Marek keep pointing me to the vararg issue...Sorry
On 31/08/11 18:04, Santiago Pericas-Geertsen wrote:
>
> On Aug 31, 2011, at 6:03 AM, Sergey Beryozkin wrote:
>
>>>> You clipped there my comment about dropping a var support for
>>>> multiple accept headers in a transitional request() :-).
>>>> Is it really close to a common use case, having a programmatic
>>>> client setting multiple accepts ?
>>>> So what about
>>>> request(String ct);
>>>> request(String ct, String at);
>>>>
>>>> as I said your example above can be handle by using request() and
>>>> then setting multiple accept headers
>>>
>>> Varargs just add extra confusion but the problem "which is which" is
>>> there even for a method(String, String).
>>
>> what do you "which is which" ? I'm proposing to bin the option to
>> specify multiple accepts in a request(...) and have two well-document
>> option, one which tales a single arg - that is accept, the one which
>> takes 2 options takes Content-Type as the 1st param, Accept - as a 2nd one
>
> I think the point here is that when you have a long list of formal
> params of the same type, the type system won't be able to help you
> detect an invalid ordering of the actual params. Typically not a problem
> with 2 params, but starts to become an issue with 3 or more (or
> varargs). It also makes the resulting code more difficult to read and debug.
>
> -- Santiago
>
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com