LocaleBased?
Description
relates to
Activity
Trac Comment 11 by @Andy Heninger—2017-09-22T00:37:48.218Z
Changing the component from textbounds, since LocaleBased also is used by Calendar, DecimalFormatSymbols, DateFormatSymbols and Format.
I agree with the goal of getting rid of this macro-based structure. I find it very confusing. A template based scheme would probably be the easiest and most direct way to replace the macros.
Trac Comment 8 by @Andy Heninger—2016-01-14T21:35:17.700Z
As best I can see, the goal of LocaleBased and U_LOCALE_BASED is to make available get and set LocaleID functions on types that have validLocale and actualLocale char[] fields, but don't have common ancestry for those fields or the functions
A pair of global template functions could probably do the job more easily, and without the need to introduce a class.
A mixin class would also be conceptually a good solution, but there are practical problems with the use of multiple inheritance in ICU class hierarchies.
Trac Comment 4 by @Steven R. Loomis—2013-03-14T06:52:32.819Z
rolling forward to 52
Trac Comment 2 by @Steven R. Loomis—2012-11-28T20:42:53.069Z
I'll propose a protected @draft or @internal function for BreakIterator subclasses to set the locale ID.
Trac Comment 1 by @Steven R. Loomis—2012-11-21T21:28:48.299Z
It's worse than that. you '''CANNOT''', using public subclass API, set the locale ID on a BreakIterator.
Why is LocaleBased a private macro based class, instead of a parent class? Seems like LocaleBased could simply be a subclass of UObject or even a mixin. Otherwise, it makes ICU classes harder to subclass without access to the special macro and functions.
For example, subclassing BreakIterator, one can't simply pass the Locale object to the parent constructor.