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

Reply via email to