On Wed, Oct 3, 2018 at 11:08 AM Michael Osipov <[email protected]> wrote:
> 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. > Ah, well, that's a matter of opinion ;-) Gary
