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 18:02:01 GMT
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


Mime
View raw message