We're updating the issue view to help you get more done. 

unum_open API is poor and inadequately documented

Description

unum_open takes the following parameters:
UNumberFormatStyle style,
const UChar* pattern,
int32_t patternLength,
const char* locale,
UParseError* parseErr,
UErrorCode* status

If the style is 0, the pattern and length are used to construct a
DecimalFormat.
Otherwise the pattern and length are ignored, and the style selects one of the
standard styles to use. This is entirely undocumented. In fact, the only way
use the pattern arguments is to specify UNUM_IGNORE as the style, but this is
not
listed as a valid style to pass to unum_open so its use is a mystery.

There used to be two perfectly reasonable, separate APIs for this, but it
looks like they were unified when the UParseError parameter was added. I think
this
unification is probably a mistake.

There also are two different kinds of pattern that (in theory) could be used,
the DecimalFormat patterns and the RuleBasedNumberFormat patterns. Currently
the
code always assumes the DecimalFormat pattern. The docs, of course, don't
describe
the contents of the pattern at all, you're just supposed to know that even
though
there is this NumberFormat abstraction layer the code basically assumes that it
is
always DecimalFormat underneath...

If the API is split again then we'd have to analyze the pattern to determine
which
kind of pattern it is. The syntax is distinct enough to make this possible, I
think.
I'm not sure the openPattern API belongs at this level at all-- it isn't on the
C++
side. I guess it is to avoid having a C variant of DecimalFormat by rolling
everything into unum, but you end up over-unifying things and requiring stuff
like
having to analyze the pattern string to disambiguate.

Status

Assignee

TracBot

Reporter

TracBot

Labels

Reviewer

None

Time Needed

None

Start date

None

Components

Fix versions

Priority

major