On Thu, Oct 4, 2018 at 8:40 AM Oleg Kalnichevski <[email protected]> wrote:
> On Thu, 2018-10-04 at 08:25 -0600, Gary Gregory wrote: > > 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 do not understand why low level APIs such I/O session and I/O reactor > interfaces were even changed _in the first place_? What was the point > of doing so? It is conventional for sockets to use milliseconds > Convention is an interesting choice of words, here is what a dictionary <https://www.google.com/search?q=Convention&oq=Convention&aqs=chrome..69i57&sourceid=chrome&ie=UTF-8> says (my emphasis): "a way in which something is *usually* done, especially within a particular area or activity." Which brings me to this Javadoc comment from Oracle Java 8 for java.net.Socket: /** * Returns setting for {@link SocketOptions#SO_TIMEOUT SO_TIMEOUT}. * 0 returns implies that the option is disabled (i.e., timeout of infinity). * * @return the setting for {@link SocketOptions#SO_TIMEOUT SO_TIMEOUT} * @exception SocketException if there is an error * in the underlying protocol, such as a TCP error. * * @since JDK1.1 * @see #setSoTimeout(int) */ public synchronized int getSoTimeout() throws SocketException { Zero mention of scale. It is only if you go and look for the setter method's Javadoc that you see mention of scale. Using the scale in the API name or using a TimeUnit parameter solves any risk of what I'll call "confusion by convention". By specifying scale explicitly, you then have to really want to crash into Mars: https://www.wired.com/2010/11/1110mars-climate-observer-report/ Gary anyway. > > Oleg > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
