Am 2018-10-03 um 18:38 schrieb Gary Gregory:
On Wed, Oct 3, 2018 at 10:18 AM Michael Osipov <[email protected]> wrote:
Am 2018-10-03 um 16:55 schrieb Gary Gregory:
On Wed, Oct 3, 2018 at 7:17 AM Oleg Kalnichevski <[email protected]>
wrote:
On Tue, 2018-10-02 at 15:34 -0600, Gary Gregory wrote:
On Tue, Oct 2, 2018 at 2:09 PM Oleg Kalnichevski <[email protected]>
wrote:
On October 2, 2018 9:57:40 PM GMT+02:00, Michael Osipov <
[email protected]> wrote:
Am 2018-10-01 um 16:33 schrieb Gary Gregory:
Also, since we are here, in the same place: "Header
getSingleHeader(String)", could be be "getHeader(String)";
since the
"Single" is implied by the singular "Header" in the API name
_and_ by
the
return type.
Thoughts on that one?
Makes sense to me.
That will break a lot of people's code. Please at the very least
deprecate
all methods.
IMO, deprecating code from one beta to another is over the top and
when do
you remove the methods, in another beta?
I imagine such methods could be removed at any point before the first
GA release.
I do not understand why making an upgrade to the next BETA simpler for
every single HC 5.0 user out there is not worth one extra commit.
Good idea. In git master:
* Deprecate and rename
org.apache.hc.core5.http.EndpointDetails.getSocketTimeout() to
getSocketTimeoutMillis().
I am not a huge fan of having the value scaling as part of the method
name. An overload as getSocketTimeout(TimeUnit) would not work anymore.
Not having the scale is a recipe for disaster -- I'm being dramatic :-)
That is just bad documentation.
We already have scale in other APIs.
Nothing prevents you from adding getSocketTimeout(TimeUnit), so what if
it's not an overload? What matters is that it would be an easy API to
understand IMO.
I do simply mean that getSocketTimeout() and getSocketTimeout(TimeUnit)
read way better thatn getSocketTimeoutMillis() and
getSocketTimeout(TimeUnit). It just looks consistent.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
