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
