On 4 June 2011 18:35, Henri Yandell <flame...@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 <seb...@gmail.com> wrote:
>> On 4 June 2011 03:44, Henri Yandell <flame...@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 <seb...@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-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
