Hi,
Mike, first off: I'm sorry if my work messed up something you were
working on locally, but hadn't committed yet. You're right that it
might have been better if I had first discussed on the list some of
what I planned to do. That said, I did make sure all the tests and the
VanillaSDK_POC example run correctly before I made any commit.
Further, I did "commit early, commit often" as much as possible, it's
just that setting up MXML required some changes in the project
structure (more on that below). I didn't see a way to make that
process more atomic and still check in only code that compiled without
errors.
A little belatedly, here is my reasoning behind most of the changes -
argued in retrospect, I didn't have a grand evil plan before I
started, I just wanted to get MXML parsing started ;-)
In general, this is how I understand the structure of the project:
there are two levels: API and implementation. The API lives in the
'org.apache.flex.compiler' packages and is mirrored in the
implementation (duh) which lives in the
'org.apache.flex.compiler.internal' packages.
Until I started out on the MXML work, we had one type of input (AS)
and two main types of output: AS and JS. This was mirrored in the
project structure:
- for AS, there is 'org.apache.flex.compiler.as' and
'org.apache.flex.compiler.internal.as'
- for JS, there is 'org.apache.flex.compiler.js' and
'org.apache.flex.compiler.internal.js'
Each of these has at least two sub packages: 'codegen' and 'driver'.
Each of these sub packages can have output type specific children,
e.g. for AMD and Goog.
Now with MXML, there is a second type of input and a third basic type
of output. So, I created 'org.apache.flex.compiler.mxml' and
'org.apache.flex.compiler.internal.mxml' and associated sub packages.
I like symmetry.
However, as there are now 2 types of input (AS and MXML), I needed to
abstract out some of the AS code that handles input, in order to share
it with the MXML code. While looking for a place to put this new 'top
level' code, I decided to put that in a package named 'common', which
I created - being a fan of symmetry - on the now familiar two levels:
'org.apache.flex.compiler.common' and
'org.apache.flex.compiler.internal.common'. Also, some of the classes
that were previously in 'as' really belong in 'common', as they are
not specific to AS.
As for the tests, I collected all the 'test base' classes, including
the new one for MXML, and put them together in
'org.apache.flex.compiler.internal.test'. While doing this, I noticed
that there were three nearly identical 'compile' methods in separate
classes, so I consolidated those into one 'compile' method, with some
supporting and overloading methods. I did not change any 'asserts' and
made sure that all tests passed at any time.
Now, for my strategy for the MXML parsing: as I said, I like symmetry.
As we did for AS, first I want to make sure that FalconJx understands
all MXML types that Falcon does (a long list that lives in the Falcon
compiler in 'org.apache.flex.compiler.tree.mxml') and is able to
output what is put in. To achieve this, I plan to write tests for each
of these types/features, much as we did for AS. Once that is
'complete', I plan to start work on the various output types, like
FlexJS and VanillaSDK. This I plan to do in a similar way as we did
for AMD and Goog, by subclassing the MXML emitter and creating
accompanying tests. So, with '-js-output-type=FLEXJS', the compiler
will produce Alex's data structures (or whatever, I'm not yet up to
speed on 'his' approach) and with '-js-output-type=GOOG' it will
output something that makes the VanillaSDK work. Again, symmetry
dictates that MXML output will be just as flexible as the AS output
is.
Mike, I do like to work with you on this project, so maybe we should
talk some more about how we can best make this work? I thought about
branching, but I couldn't find a workable way to branch only
'compiler.jx' without also having to create a branch of the 'compiler'
and 'compiler.jx.tests'. Also, merging stuff from a branch that
changed so much might have been more work than refactoring your local
code after this monster commit of mine?
Also, with MXML now in place, there will be no need for this kind of
major architectural changes anymore. Any changes, at least for the
foreseeable future, should be much more incremental and 'localised' in
nature, allowing us both (and many, many others!?) to work on the code
simultaneously without getting in each other's way.
Now you know what I have planned, maybe you can explain what you are
working on, so I can make sure my messing around won't hurt what
you're doing too much?
EdB
On Fri, Mar 1, 2013 at 5:54 AM, Alex Harui <aha...@adobe.com> wrote:
On 2/28/13 4:22 PM, "Michael Schmalle" <apa...@teotigraphix.com> wrote:
I want 1451312 reverted
"Another major refactoring, but..."
Right, WAY TO MAJOR. This was to much to change in one commit.
Mike
I'm not sure this counts as a technical reason. Is there a technical issue
with the refactoring? If the problem is that it made it hard for you to
contribute to the code because you have to figure out where everything moved
to, that is a concern worth voicing, but if the refactoring has technical
merit then I don't think he has to revert.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
