commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <ggreg...@seagullsw.com>
Subject RE: [lang] DateUtils constants should be long
Date Sun, 21 Dec 2003 19:47:48 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message