On Thu, Mar 3, 2011 at 10:04 AM, Eric Ayers <[email protected]> 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. > I think that would definitely be an improvement on the static method. > 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. > Nah, instance method is better than this. > 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? > Actually, that might not be too hard at all. > 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.) > Hmm, MutableJavaResource is a bit of a beast these days. Kind of cumbersome that reified Class objects are the primary api there. If Class objects were a convenience, and the underlying api was in terms of stuff you could get from a Class object, then you could have a Class convenience constructor for most of the cases, and special-case JavaScriptObject to work from bytes. You could get the bytes easily enough by instantiating a CompilationStateTestBase and grabbings its 'state', which will already contain a Unit for JSO, the one from JavaResourceBase.JAVASCRIPTOBJECT. I guess it all depends on how serious you are about removing TypeOracleMediatorFromByteCodeTest. If you are going to get rid of that anyway, MutableJavaResource gets a lot simpler, and it becomes pretty easy to just utilize JavaResourceBase.JAVASCRIPTOBJECT. Scott -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
