Are you in a big hurry to get this in? If not, it seems like the perfect reason to go back to the drawing board with JClassLiteral to make it not suck now that we have a much better idea what we really want out of it. Otherwise, it feels an awful lot like we're piling suckitude on top of suckitude. :( Can you guarantee that one or the other of the classSeedFunc logic or the typeName logic will always get optimized out? I tend to think that you cannot make this guarantee because of synthetic class literals like String[].class.
On Thu, Apr 2, 2009 at 11:12 AM, BobV <b...@google.com> wrote: > On Tue, Mar 31, 2009 at 9:09 PM, BobV <b...@google.com> wrote: > > On Tue, Mar 31, 2009 at 8:12 PM, Scott Blum <sco...@google.com> wrote: > >> This seems kinda hacky since you could recompute the seed func name at > >> compile time during GenerateJavaScriptAST? > > > > I thought about that, but discounted it because > > GenerateJavaScriptAST would have to take a look at the pruned / > > mangled / optimized by as-yet-unknown call sites of CreateForFoo() and > > determine which parameter to replace (assuming any parameters were > > left) instead of being told exactly what to do via the Java AST. That > > seemed more likely to break over time as well as contribute to clutter > > in the string literal pool. > > @Scott, > > Can I get a thumbs up/down on this approach as an interim solution? > Otherwise, I can come up with some other way of de-mangling class > identity for instantiable types at runtime with a method similar to > the old GWT.getTypeName(). > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
