Quoting Erik de Bruin <e...@ixsoftware.nl>:
Mike, While trying to stay out of your hair in the FalconJx code, I thought I might spend some time translating the tests you wrote for the AS output to tests for the JS + 'goog' output. I'm doing this by copying the AS tests, renaming them, converting them to subclasses of the AS tests and pointing them to the 'GoogBackend' (using the code from your test class).
The GoogBackend needs to be made a class, that was just a quick java inner class for the test. I will move it into the goog package I mention below.
An observation: some methods of JSGoogEmitter rely on 'globals' like 'classDefinition', which are not set when the methods are called from the tests. I'm not very familiar with JUnit (or unit testing in general), so a little pointer on how to fix this would be much appreciated.
Actually, they are not really globals. They are reminiscent of the initial prototype and should be removed. I decided to use AST for any TypeNode quires since I wanted granular testing. Actually from what I remember, I'm really not using them because the AS tests wouldn't work if I was dependent on them.
Now looking at the code, yeah I refactored them out of the AS production code but I didn't get to the goog emitter, that was a copy and paste of some commented out code before the AS refactor.
Meanwhile I'll put all the tests (with the 'assertOut' commented out) in a 'goog' package in 'org.apache.flex.js.internal.js.codegen'. Maybe we want to put the 'goog' Emitter classes of the compiler also in a 'goog' package, to increase the separation between them and other output types?
Right, I was getting to that as well. When I'm programming this type of stuff, sometimes its like lightning and I just want to get an idea out and not worry about the bookkeeping. :)
Probably; org.apache.flex.compiler.internal.js.goog, I think the codgen should be more abstract js stuff in there.
I'm going to do one more refactor on the emitter and docemitter. I'm half way done. Then I will move some packages around like we said, things should be pretty stable from the stand point of where classes and interfaces go.
If I have a question I'll ask your opinion about placement. Mike
EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
-- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com