> 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]

Reply via email to