commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian S O'Neill <brone...@earthlink.net>
Subject Re: [lang] DateUtils constants should be long
Date Sun, 21 Dec 2003 19:58:41 GMT
There's a difference between specifying a unit of time to sleep vs 
defining a constant. The JRE APIs are inconsistent. The google search 
brings up:

http://java.sun.com/j2se/1.3/docs/api/java/awt/Robot.html

which accepts millisecond sleep times as ints. Then there's:

http://java.sun.com/j2se/1.3/docs/api/java/net/Socket.html

which accepts millisecond timeouts as defined by ints. Also:

http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/AbstractButton.html#doClick(int)

Gary Gregory wrote:

>Brian: "I think that constant values should always be stored using the type
>that best represents them"
>
>Perhaps the best reason for switching [lang] to using a long to represent
>milliseconds is that JRE APIs do so. For example: 
>
>http://java.sun.com/j2se/1.3/docs/api/java/lang/System.html#currentTimeMilli
>s()
>
>http://java.sun.com/j2se/1.3/docs/api/java/lang/Object.html#wait(long)
>
>More:
>http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=utf-8&as_qdr=all&q=millis
>econds+site%3Ajava.sun.com+%2Fj2se%2F1.3%2Fdocs%2Fapi&btnG=Google+Search
>
>Gary
>
>  
>
>>-----Original Message-----
>>From: Brian S O'Neill [mailto:broneill@earthlink.net]
>>Sent: Sunday, December 21, 2003 10:02
>>To: Jakarta Commons Developers List
>>Subject: Re: [lang] DateUtils constants should be long
>>
>>The DateTimeConstants class in Joda-time originally defined these kinds
>>of constants as ints. Then they switched to longs, however, some classes
>>that depended on these constants were required to downcast to ints.
>>Although it caused no harm since the values can fit in an int, I was
>>concerned that some users might think that storing the value in a long
>>is required.
>>
>>As of now, the constants are defined as ints again. If you are using
>>these constants for performing calculations, you may need to ensure that
>>the constant is cast to a long. But if you're doing calculations, then
>>you need to be careful anyhow, and Joda-time should contain enough
>>functionality such that you won't need to perform your own calculations.
>>
>>By storing the constant as a long, an assumption is made about how the
>>user is going to be using it. What if the user needs to do some
>>floating-point calculations? Maybe they'll forget to cast the int or
>>long into a double? Should the constant be then stored as a double
>>instead? It fits. Again then this gives the impression that the
>>constants must be represented as this type, and downcasts may cause loss
>>of precision.
>>
>>Whenever doing calculations, you always need to be aware of the
>>precision requirements. I think that constant values should always be
>>stored using the type that best represents them, although don't bother
>>using byte or short since the Java platform always casts those into
>>ints. Users of these constants are responsible for upcasting them into a
>>type that is required for their calculation.
>>
>>Stephen Colebourne wrote:
>>
>>    
>>
>>>Hmmm, I hadn't thought about deprecation. But I think we do have to.
>>>      
>>>
>>Bother.
>>    
>>
>>>Stephen
>>>
>>>----- Original Message -----
>>>From: "Gary Gregory" <ggregory@seagullsw.com>
>>>
>>>
>>>      
>>>
>>>>Hm... I thought the proposal was just to change the types from int to
>>>>        
>>>>
>>long
>>    
>>
>>>>on the existing fields as opposed to creating new fields.
>>>>
>>>>Obviously this would not be backwards compatible but if we are saying
>>>>        
>>>>
>>that
>>    
>>
>>>>the fact that they are ints is, in actuality, a "bug", then, maybe,
>>>>
>>>>
>>>>        
>>>>
>>>perhaps,
>>>
>>>
>>>      
>>>
>>>>it would be acceptable to break call site... arg, probably not.
>>>>
>>>>It certainly would fix the client code that is just expressions (as
>>>>
>>>>
>>>>        
>>>>
>>>opposed
>>>
>>>
>>>      
>>>
>>>>to assignments to ints which would no longer compile). It's never nice
>>>>        
>>>>
>>to
>>    
>>
>>>>break client code of course and deprecation is just for that purpose.
>>>>
>>>>So, all of that round and round to say I agree with you in the end! ;-)
>>>>
>>>>Would anyone else care to comment?
>>>>
>>>>Gary
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>-----Original Message-----
>>>>>From: Phil Steitz [mailto:phil@steitz.com]
>>>>>Sent: Saturday, December 20, 2003 15:47
>>>>>To: Jakarta Commons Developers List
>>>>>Subject: Re: DO NOT REPLY [Bug 25627] - [lang] DateUtils constants
>>>>>
>>>>>
>>>>>          
>>>>>
>>>should
>>>
>>>
>>>      
>>>
>>>>>be long
>>>>>
>>>>>Gary Gregory wrote:
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>Looking for a volunteer (Stephen? ;-) I as I in ultra-busy mode...
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>I will volunteer for this.  I assume that since these are (2.0
>>>>>          
>>>>>
>>released)
>>    
>>
>>>>>public fields, we need to deprecate and rename. I would use
>>>>>          
>>>>>
>>MILLIS_PER_*
>>    
>>
>>>>>for the new names. Sound OK?
>>>>>
>>>>>Phil
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>Gary
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: bugzilla@apache.org [mailto:bugzilla@apache.org]
>>>>>>>Sent: Thursday, December 18, 2003 12:53
>>>>>>>To: commons-dev@jakarta.apache.org
>>>>>>>Subject: DO NOT REPLY [Bug 25627] - [lang] DateUtils constants
should
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>be
>>>
>>>
>>>      
>>>
>>>>>>>long
>>>>>>>
>>>>>>>DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
>>>>>>>RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
>>>>>>><http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25627>.
>>>>>>>ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
>>>>>>>INSERTED IN THE BUG DATABASE.
>>>>>>>
>>>>>>>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25627
>>>>>>>
>>>>>>>[lang] DateUtils constants should be long
>>>>>>>
>>>>>>>ggregory@seagullsw.com changed:
>>>>>>>
>>>>>>>         What    |Removed                     |Added
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>-----------------------------------------------------------------------
>>>>>          
>>>>>
>>-
>>    
>>
>>>>>--
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>>--
>>>>>>>           Status|NEW                         |ASSIGNED
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>------- Additional Comments From ggregory@seagullsw.com  2003-12-18
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>20:52
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>>-------
>>>>>>>Indeed, since these values express milliseconds and APIs which
take
>>>>>>>              
>>>>>>>
>>or
>>    
>>
>>>>>>>return
>>>>>>>millisconds usually do so a longs.
>>>>>>>
>>>>>>>---------------------------------------------------------------------
>>>>>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>>>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>>>
>>>>>
>>>>>          
>>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>>      
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>    
>>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message