That sounds better, but is there a reason why JavaScriptObjectNormalizer was doing this pre-optimization in the first place?
Anyway, in favor of keeping the 'null instanceof JSO' behavior is that the following code currently will not do a null check either: SomeJso foo = getNull(); foo.someMethod() -> translates to jso$someMethod(foo), even if foo is null; In most cases, you'll still get an NPE, when interior of the function tries to deref 'this'. I'll look at re-rolling this using your proposal. -Ray On Thu, Feb 17, 2011 at 3:06 PM, <[email protected]> wrote: > Dude, I dunno... null instanceof JSO just seems wrong to me. I hate to > torpedo this, but I feel like we need to step back and figure out > another strategy for getting in the optimization we want to see happen, > without abusing instanceof that way. > > Let's take a step back. What if JavaScriptObjectNormalizer *never* > inserted the dual dispatch code? What if we ran through the > optimizations as per normal without that in there? > > - TypeTightener could tighten a SingleJsoInterface into JSO in cases > where no Java impl existed. > - Make calls static could then transform the instance call into the > correct static call. > - Anything that survives optimizations, we clean up in JsoDevirtualizer, > which already correctly handles hashCode/equals/toString. > > Thoughts? > > > http://gwt-code-reviews.appspot.com/1351801/diff/8001/6003 > > File dev/core/src/com/google/gwt/dev/jjs/ast/JTypeOracle.java (right): > > http://gwt-code-reviews.appspot.com/1351801/diff/8001/6003#newcode601 > dev/core/src/com/google/gwt/dev/jjs/ast/JTypeOracle.java:601: public > boolean isSingleJsoImpl(JReferenceType type) { > FWIW, I actually abhor the term "SingleJsoImpl", because what it really > means is "an interface that is implemented by a single JSO" which is not > at all obvious. "SingleJsoInterface" would be a much clearer term to > me. > > > http://gwt-code-reviews.appspot.com/1351801/show > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
