commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [LANG] change FormatCache.getDateTimeInstance() to use int
Date Sat, 04 Jun 2011 18:00:28 GMT
On 4 June 2011 18:35, Henri Yandell <flamefew@gmail.com> wrote:
> Seems good. Something other than NULL probably; and probably should
> come up with some bizarre negative number to stay out of the way of
> any future JDK items.

Yes, that is a possible issue here. The current JDK only uses positive
integers, so -1 may be OK.

FormatCache already has the following constant:

    /**
     * No date or no time.  Used in same parameters as
DateFormat.SHORT or DateFormat.LONG
     */
    static final int NONE= -1;

This is not currently used, but perhaps should be made public and used for this.

Choosing a suitable value is either as simple as leaving it at -1 or
it could be impossible.
Every int value may mean something to someone (*), and the JDK writers
may choose to use the same bizarre number in future...

Alternatively, we do away with the special null code and have 3 methods:

getDateTimeInstance
getDateInstance
getTimeInstance

This would solve the issue with no possible clashes, and does not
affect the external API AFAICT.

Another related issue - not sure why FastDateFormat creates aliases
for the DateFormat constants:

    /**
     * FULL locale dependent date or time style.
     */
    public static final int FULL = DateFormat.FULL;

Why not just use the originals? If new values are added, at the very
least the Javadoc will have to be changed.

(*) especially if their name is Ramanujan ;-)

> On Fri, Jun 3, 2011 at 8:06 PM, sebb <sebbaz@gmail.com> wrote:
>> On 4 June 2011 03:44, Henri Yandell <flamefew@gmail.com> wrote:
>>> Looking more at this one, it looks like the Integer is required as
>>> null is a valid use case. So moving simply to int is out, but
>>> rethinking it seems very doable.
>>
>> I did some work on this, and I think we can add another style value
>> which means don't use the date or time
>>
>> We don't require null, we just require a marker value that is not
>> otherwise used.
>>
>> For example, define FastDateFormat.NULL = -1 and check for that.
>>
>>> Note that this isn't a public API; FormatCache is for now a
>>> refactoring out of FastDateFormat to allow a later FastDateParser.
>>>
>>> I've added a TODO item to solve this before changing the class to public.
>>>
>>> Hen
>>>
>>> On Wed, May 18, 2011 at 6:37 AM, sebb <sebbaz@gmail.com> wrote:
>>>> I think the method (new to 3.0)
>>>>
>>>> FormatCache.getDateTimeInstance(Integer dateStyle, Integer timeStyle,
>>>> TimeZone timeZone, Locale locale)
>>>>
>>>> should be changed to use ints, as all the existing callers use ints.
>>>>
>>>> Furthermore, the parameters have to be unboxed in order to pass them
>>>> to DateFormat, so the boxing/unboxing is unnecessary and wasteful.
>>>>
>>>> OK?
>>>>
>>>> I've not raised a JIRA for this because it is new code that has not
>>>> been released - but I'm happy to do so if others think a JIRA entry is
>>>> necessary here.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message