Re: [icu-design] ICU4C 61 API Discussion/Proposal: API for date/time field names

[Peter E. <pe...@ap...>]

Hi Markus, thanks for comments, responses inline.

> On Feb 9, 2018, at 11:54 AM, Markus Scherer <mar...@gm...> wrote:
> 
> On Thu, Feb 8, 2018 at 10:26 AM, Peter Edberg <pe...@ap... <mailto:pe...@ap...>> wrote:
> Currently, DateFormatSymbols has constants or enum values for specifying display width independently of symbol type.
> • Java DateFormatSymbols: WIDE, ABBREVIATED, NARROW, SHORT (between ABBREVIATED and NARROW)
> • C++ DateFormatSymbols::DtWidthType: ABBREVIATED, WIDE, NARROW, SHORT
> However, these are not available in plain C, DateTimePatternGenerator does not currently depend on DateFormatSymbols, and the selection of display widths available for calendar symbol names is not necessarily be the same as the selection for field display names (and in fact some calendar symbols have the additional SHORT width). Therefore I propose a new enum in DateTimePatternGenerator for the available display widths.
> 
> C. Specific proposal, based on the above discussion
> 
> # Java DateTimePatternGenerator, add:
> 
>     public enum DisplayWidth {
>         WIDE,
>         ABBREVIATED,
>         NARROW
>     }
> 
>     java.lang.String getFieldName(int field, DisplayWidth width);
> 
> # C udatpg.h, add
> 
> typedef enum UDateTimeWidth {
>     UDATPG_WIDE,
>     UDATPG_ABBREVIATED,
>     UDATPG_NARROW,
>     /**
>      * @deprecated
>      */
>     UDATPG_WIDTH_COUNT
> } UDateTimeWidth;
> 
> Please do not add a new "COUNT" enum constant.

Not even for use by internal arrays whose dimensions depend on this? How will we make those adjust in view of the fact that more width values may be added?

> Can we make these enums more generic, since we seem likely to need them again in other new date/time APIs?
> 
> For example,
> - in Java, make it a standalone enum DateTimeWidth? or put it into a new class DateTimeOptions as enum Width?
> - in C, put it into udat.h or a new datetimeoptions.h (like the new stringoptions.h)?

In general I would like to do that. However, different sets of widths are available for different types of symbols. For  calendar symbols we have WIDE, ABBREVIATED, SHORT, NARROW (amnd for weekdays, SHORT is often different than ABBREVIATED). For the fields data we currently have just WIDE, ABBREVIATED, NARROW. I guess we could handle that in code, e.g. mapping SHORT to ABBREVIATED. But it does lead to more hacks.

> 
> markus

- Peter E

> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
> icu-design mailing list
> icu...@li...
> To Un/Subscribe: https://lists.sourceforge.net/lists/listinfo/icu-design