On Thu, Oct 4, 2018 at 12:47 PM Michael Osipov <[email protected]> wrote:
> Am 2018-10-04 um 17:38 schrieb Gary Gregory: > > 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... > > You probably misunderstood me. I said I do not like to have the scale in > the method name, but the scale is part of the docs and maybe have an > overload with TimeUnit with explicit scale. I don't this that this is an > argument circle. > So we can break this down to two decisions: (1) Should we rename all get<SomeName>Millis() methods to get<SomeName>? (2) Should we add a getSomeName(TimeUnit) method for each get<SomeName>[Millis]() method? Gary > > Michael >
