On Thu, Oct 4, 2018 at 9:29 AM Michael Osipov <[email protected]> wrote:
> > Gesendet: Donnerstag, 04. Oktober 2018 um 16:25 Uhr > > Von: "Gary Gregory" <[email protected]> > > An: "HttpComponents Project" <[email protected]> > > Cc: "Michael Osipov" <[email protected]> > > Betreff: Re: TimeoutMillis is horrible > > > > On Wed, Oct 3, 2018 at 2:15 PM Gary Gregory <[email protected]> > wrote: > > > > > AFK ATM. I can do the TimeUnit API when I get back. > > > > > > > Hm... should this be done for all APIs that return a time in a scaled > named > > in the API name (or not) ? > > I'd go with get<name>Timeout() first and add the overload on request. > There is > no need to make additional work if it is not used at all. > I think we are going in a circle ;-) I am against any unscaled API names unless you pass a TimeUnit. All current API names are scaled. Feel free to commit otherwise of course but I think we must have consistency across APIs... Gary > > > > > > > Gary > > > > > > On Wed, Oct 3, 2018, 13:18 Oleg Kalnichevski <[email protected]> wrote: > > > > > >> On Wed, 2018-10-03 at 12:15 -0600, Gary Gregory wrote: > > >> > On Wed, Oct 3, 2018 at 11:08 AM Michael Osipov <[email protected] > > > > >> > > >> ... > > >> > > >> > > 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 > > >> > > >> I also find `TimeoutMillis` just outright hideous. I would very much > > >> rather have #getSocketTimeout(TimeUnit) as Michael proposes. > > >> > > >> Oleg > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: [email protected] > > >> For additional commands, e-mail: [email protected] > > >> > > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
