+1 Stephen ----- Original Message ----- From: "Gary Gregory" <[EMAIL PROTECTED]> > > I am +1 for changing to longs and deprecating. > > +1 > > > -----Original Message----- > > From: Phil Steitz [mailto:[EMAIL PROTECTED] > > Sent: Monday, December 22, 2003 11:54 > > To: Jakarta Commons Developers List > > Subject: Re: [lang] DateUtils constants should be long > > > > Brian S O'Neill wrote: > > > 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.htm > > > > > > which accepts millisecond timeouts as defined by ints. Also: > > > > > > > > http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/AbstractButton.html#do > > Click(int) > > > > > > > All of these are examples where a value greater than integer.MAX_VALUE > > would not make sense (the first one in fact throws if the value is > > > 60,000). As indicated in the bug report, there are natural applications > > of the DateUtils constants where overflows will happen. The point is that > > it is expected that these contants will be used in computations. > > > > So what is the verdict here, folks? I would like to either make the > > change (including deprecation) or close the ticket as WONTFIX. I am +1 > > for changing to longs and deprecating. > > > > Phil > > > > > > 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#currentTimeMil > > li > > >> > > >> 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: commons-dev- > > [EMAIL PROTECTED] > > >>>>>>>> For additional commands, e-mail: > > >>>>>>>> [EMAIL PROTECTED] > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>>>> ------------------------------------------------------------------- > > -- > > >>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >>>>>> For additional commands, e-mail: commons-dev- > > [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] > > > > > > > > > > > --------------------------------------------------------------------- > > 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]
