I know that adding more magic methods is generally frowned upon, but the advantage here is that a String literal can be made available at compile time, allowing the injection of a minimal-overhead replacement. If, for any reason, the String is not a literal, we can emit a warning about the runtime library being included and just let it go to the runtime StringFormat tool.
Given how likely a formatting String is to be a constant, I think it would be worth it; if anyone is interested in collaborating, I do have simple magic method injection running on my fork, if we prototype it and it goes (provably) well, then perhaps we could submit a patch to include the new magic method in UnifyAst. Should the team decide that we don't want any magic methods, then the other alternative would be a Java 8 compiler plugin; I have a prototype which looks up calls to GWT.create and replaces them, so looking up String.format and emitting a super-sourced copy with a generated replacement should also be possible. How to integrate that as a pre-build step is another question, but the important thing is that it is possible and we do have options for how we want to implement this. -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/f6ad18fa-c6d5-4180-9105-6659f420fc05%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
