[haiku-development] Re: Some questions about the locale kit API
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 10 Jan 2010 17:04:11 +0100
On 2009-12-30 at 12:21:43 [+0100], PulkoMandy <pulkomandy@xxxxxxxxx> wrote:
Disclaimer: I haven't looked into the original locale kit code for quite a
few years and really don't recall much really. I also haven't had a closer
look at the current state of Haiku's locale API.
> It's about time to start working on Locale Kit's API for formatting
> numbers. Here is an UML diagram of the current status :
> http://pulkomandy.ath.cx/drop/localekitformatters.png
>
> Most of the class look like they are incomplete, and I have some troubles
> understanding the structure. So here are some questions for you :)
>
> a) If I understand it, the only purtpose of the *Format classes is to hide
> the *FormatImpl to the outside of the locale kit to keep binary
> compatibility.
I don't think that's the reason, since the *FormatImpl classes were
intended to be public as well, just for use for locale add-on writers. I
don't really recall what the reason for the two class hierarchies was. It
might be that there was ref-counting planned or maybe something else
entirely. If they still exist I would recommend digging the archives of the
mailing list we had been discussing this on (OpenTracker ML?).
> I am wondering if that is really needed. The typical use
> case for these class would be :
>
> - Ask the Locale Kit to give you the current default country,
> - The BCountry class already have FormatInteger and FormatFloat methods
> that you would use in most cases.
Either the BCountry class is misnamed or the methods are misplaced. I don't
see a the reason why a country couldn't have more than one locale (that's
definitely the case language-wise, not sure about formats). Furthermore the
user should be able to set her preferred format options independently of a
country.
Other than that I partially agree, the locale kit should give you a
format/formatter class and could (additionally) provide shortcut methods
directly.
> You may still want to use your own formatter in some corner cases, like
> displaying an hexadecimal number in some technical application. This can
> be done either by growing the BCountry class with FormatHexNumber, or
> allowing users to instanciate and use NumberFormat directly.
>
> b) The GenericNumberFormat class looks useless, and so do the *Parameters
> classes. They seem to be there to do ICU's work, right ?
The BGenericNumberFormat class allows you to format and (yet missing) parse
numbers of a format defined by a set of parameters (like base, decimal
separator, grouping, etc.). If ICU can do that, then the class is indeed
superfluous. I don't see how the *Parameters classes are superluous,
though, unless you have another plan, how to specify the parameters.
> c) I'm not sure about the use of Format and NumberFormat. They make for a
> nice inheritance diagram but FloatFormat and IntegerFormat doesn't
> actually have anything in common. Is it ok to have such an useless diagram
> only for user-friendlyness, knowing that you will never have to use these
> classes ?
It doesn't harm at least. :-)
> Is there a use case for them I missed ?
ATM there isn't, which doesn't mean there would never be one, though. E.g.
we could decide to add methods for formatting/parsing BVariants, which
might better fit the BNumberFormat (or even BFormat) class.
CU, Ingo
PS: I very much recommend having a look at Java's locale API, which IMO is
very well thought out.
Other related posts:
