You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2003/12/21 17:24:41 UTC
Re: [lang] DateUtils constants should be long
Hmmm, I hadn't thought about deprecation. But I think we do have to. Bother.
Stephen
----- Original Message -----
From: "Gary Gregory" <gg...@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
Re: [lang] DateUtils constants should be long
Posted by Brian S O'Neill <br...@earthlink.net>.
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" <gg...@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