On Fri, Aug 27, 2010 at 11:28 AM, Scott Blum <sco...@google.com> wrote:
> On Fri, Aug 27, 2010 at 11:21 AM, John Tamplin <j...@google.com> wrote:
>>
>> Why do that every time you run the generator rather than once when you
>> import the CLDR data?
>
> Oh, you know what, I kind of forgot that we're the only ones who actually
> implement currency list.
> Which actually brings up another interesting point... why have a generator
> at all? Why not have the CLDR data importer produce static java files one
> time?
I did do exactly that for DateTimeFormatInfo (see
DateTimeFormatInfoImpl_<locale>.java). When I wrote CLG, I kept the
inheritance hierarchy the same as it was originally which meant that the
actual inheritance between locales could vary depending on how things were
specified (particularly dealing with aliases and default scripts -- ie, if
you specified en_Latn_US then that would be the leaf node which inherited
from en_US rather than the other way around). For DTFI, I decided that the
differences between these were not significant and if someone was doing
something really obscure (like splitting messages into en_US and en_Latn_US
that overlaid each other) they could deal with the change, and it let us
avoid running the generator at all (and some of it was fairly expensive,
calling ICU4J to generate a localized date pattern matching various
criteria).
This could be done the same way, but the version for runtime locales would
have to generate a version that did a runtime switch between the matching
sublocales in a given permutation. So, normally you would just let
GWT.create(CurrencyListImpl.class) return CurrencyListImpl_locale (making
CurrencyList an interface and moving most of the definition to
CurrencyListImpl), but if runtime locales were in use you would have to
generate a CurrencyListImpl_runtime_en which contained something like:
class CurrencyListImpl_runtime_en implements CurrencyList {
private static final CurrencyList INSTANCE;
static {
String runtimeLocale = LocaleInfo.getCurrentLocale().getLocaleName();
if ("en_US".equals(runtimeLocale)) {
INSTANCE = new CurrencyListImpl_en_US();
} else if ("en_AU".equals(runtimeLocale)) {
INSTANCE = new CurrencyListImpl_en_AU();
} ... other locales supported by the app that inherit from en
} else {
INSTANCE = new CurrencyListImpl_en();
}
}
// delegate everything to INSTANCE.foo
}
So the generator algorithm would look like this:
- If runtime locales are in use, generate a runtime-selection
implementation and return that class
- Otherwise, find the best match of CurrencyListImpl_locale and return
that name
In fact, that could probably just be LocalizableGenerator's approach so
user-written Localizable subclasses would get the benefit.
In summary, yes it could happen and it would probably be a good idea, but it
is a lot of work.
--
John A. Tamplin
Software Engineer (GWT), Google
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
