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:[EMAIL PROTECTED] > 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" <[EMAIL PROTECTED]> > > > > > >>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:[EMAIL PROTECTED] > >>>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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >>>>>Sent: Thursday, December 18, 2003 12:53 > >>>>>To: [EMAIL PROTECTED] > >>>>>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 > >>>>> > >>>>>[EMAIL PROTECTED] changed: > >>>>> > >>>>> What |Removed |Added > >>>>> > >>>>> > >>>----------------------------------------------------------------------- > - > >>>-- > >>> > >>> > >>>>>-- > >>>>> Status|NEW |ASSIGNED > >>>>> > >>>>> > >>>>> > >>>>>------- Additional Comments From [EMAIL PROTECTED] 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: [EMAIL PROTECTED] > >>>>>For additional commands, e-mail: [EMAIL PROTECTED] > >>>>> > >>>>> > >>> > >>> > >>>--------------------------------------------------------------------- > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
