Sigh: None of these alternative options are panning out for me
On 2011/03/03 15:05:21, zundel wrote:
After sleeping on the static rogue setter, I don't like it much either
and
came up with some alternatives:
1) Would it be more palatable to turn setJavaScriptObjectClass() it
into an
instance method? That way, we wouldn't have to reset the static
variable
each time in tearDown and the override would last for only one
instance of a
TypeOracle. That is the simplest thing I can think of.
This works out great for TypeOracleMediatorFromByteCodeTest, but when we compile from source in TypeOracleMediatorFromSourceTest, the place we need to get in to modify the Type Oracle instance is nested inside of CompilationState which is also nested inside of CompilationStateBuilder. That means disruption to these other two classes. Seems like the test would be even more intrusive if I did that - what do you think?
2) We could make the setter just add to a static list of alternative
class
names to be treated like JavaScriptObject. That would incur a slight run-time penalty in computeSingleJsoImplData() to check against a list
of
strings instead of just a single one. But then we wouldn't have to
worry
about resetting the name.
This one would still work, but has the unpalatable runtime penalty.
3) Do you think it would be feasable to taking com.google.gwt...mediatortest.JavaScriptObject.class object's bytecode
and
re-write the package using ASM?
This would work great for JavaScriptObject itself, but not references in the several derived classes we create and compile into binary in the mediatortest packages. We'd have to rewrite the JavaScriptObject references in those classes too.
4) You suggested squirreling away a copy of com/google/gwt/core/client/JavaScriptObject.class somewhere on the
classpath
for the gwt-dev project and using it as the source for the bytecode.
This
would require some minor refactoring of CheckedJavaResource and
subclasses
in TypeOracleMediatorTest. To me, this is kind of obscure black magic (comparted to how the rest of the tests are implemented.)
Same problem as #3, we could handle JavaScriptObject that way, but we'd also have to handle all the derived classes the same way so that they derived from com.google.gwt.core.client.JavaScriptObject. No wonder there were no tests for this logic before :(
On Wed, Mar 2, 2011 at 10:02 PM, Scott Blum <mailto:[email protected]>
wrote:
> On Wed, Mar 2, 2011 at 7:21 PM, Eric Ayers
<mailto:[email protected]> wrote:
> >> @Scott: I was not planning to revert the diff cheese. This uses the >> recently updated official gwt-format.xml autoformatting for
Eclipse. I've
>> already volunteered to go through and run the autoformatter to
bring
>> existing source up to date. > > > Right, I'm just making the point that it would be great if you could
land
> that first, so that when you submit this change, it won't mix the
formatting
> & semantic changes into one CL. > > Per our face to face, it'd also be good if you could leave a TODO in > TypeOracle to remove the rogue setter once > TypeOracleMediatorFromByteCodeTest is gone. >
-- Eric Z. Ayers Google Web Toolkit, Atlanta, GA USA
http://gwt-code-reviews.appspot.com/1369805/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
