On Wed, Oct 21, 2009 at 3:52 PM, John Tamplin <[email protected]> wrote:
> The problem is more than that. As mentioned above, the actual compiled code
> is frequently different depending on the messages, such as when the
> parameters are re-ordered in different locales or have different formatting
> patterns. Basically allowing them to be switched outside of a full compile
> means the format strings have to be parsed at runtime, which IMHO is an
> expensive price to pay.
I don't know if this solves the right problem, and maybe it would be
more trouble than it's worth, but I think you could straddle the
middle here.
Take your earlier example:
* "Folder name: {0} File name: {1}" in English
* "xxx {1} yyz {0} xkx" in some other locale
Presumably that compiles down (in English) to something like this:
"Folder name: " + valueOfZero + " File name: " + valueOfOne
and then the optimizer has its way and things get inlined, propagated,
or whatever. What if you just used variables instead and populated
the variables via some external mechanism. Something like this:
$locConst0 + valueOfZero + $locConst1 + valueOfOne
The compiler could generate the names "folderNameConst" and
"fileNameConst" in some deterministic way so that you could take the
original list of properties
some.developer.chosen.name="Folder name: {0} File name: {1}"
and map it to this
$locConst0="Folder name: "
$locConst1=" File name: "
in an automated way. If the "automated way" is a tool you could run
separately from a full compile, Thomas could rig it into his
internationalizing servlet such that the user updates the original
properties file, and then the tool regenerates the GWT-optimized
version. Perhaps the result wouldn't be as thoroughly optimized as
the current system (no way to detect that $locConst0 and $locConst1
are the same, for example), but it would be more optimized than
parsing message format strings at run time and it would (I think)
solve Thomas' problem.
Thoughts?
Ian
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
