Am 2018-10-04 um 22:40 schrieb Gary Gregory:
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?
Correct. I'd for (1) in the first round. (2) is nice to have.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
