On Wed, Feb 9, 2011 at 3:36 PM, <[email protected]> wrote: > It is strange, then again, it is strange that a JSO that is null can > still be invoked. :) However, I think I've come back to sanity on > rethinking this. Since it is only used for a single use case in my Json > library (JsonNull), I think I'll just change the API slightly. I wanted > an "unwrapped" JsonNull to represent json nulls (most APIs use a Java > wrapper). Instead, I'll just use the real 'null', and add an extra > method to check for the difference between 'null' and undefined.
Thanks. :) It would seem really strange if all Java nulls were implicitly treated as JSOs! > This is a different issue, and my gut says they will only partially get > cleaned up. Consider: > > Cast.isJavaObject(foo) ? foo.method() : Jso$foo$method(); > Maybe that pass is simply generating the wrong code. I'm not saying this, by itself, would work, but maybe the right solution involves generating something like: (foo instanceof JavaScriptObject) ? JsoFoo.$method(foo) : foo.method() So that dead code can optimize the instanceof test at some point. Or, maybe we should leave the call site alone initially... If we model the JSO method as having an upref to the interface method, CFA and TypeTightener might do the right things implicitly, then we modify the appropriate optimizer pass to convert the interface call into the JSO direct call if that's the only viable option. Then we add the appropriate logic to JsoDevirtualizer to handler this post-optimization for cases that still exist. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
