On Tue, 2005-02-22 at 18:19, David Johnson wrote (more than required
...):

> In terms of the Vulcan engine, a CLocale super-class that defines the
> abstract or (default behaviors - binary comparison?), with subclasses
> for each of the supported language/collation mechanisms. Like the Java
> mechanism, specific locales can be addressed via a static method call
> that uses reflexion or dynamic library registration (.dll or .so) to
> isolate the localization code from the core engine code.

<snip ... >

Segregating the locale into its own class that can in turn be isolated
to a .dll or .so with dynamic registration at runtime allows the
localization to be installed (built in) with a small number of cases
early on, and then expand support over time without having to recompile
the core engine. It also allows the engine to be completely agnostic
towards the question of collations, so it simplifies the code.

Over time, the separate class files can be rolled into the main build as
staged rollouts. Bug fixes that impact only a single locale can be
rolled out as shared libraries that override to the compiled in classes.

Oh, yes, you would need to segregate the compare method into case
sensitive and case-insensitive methods. The compare methods are
essentially big switch statements, and would most likely form the bulk
of the Locale class code.