To me, your emotions show your involvement and commitment to the project. Nobody can work together in perfect harmony all the time :-) Just important that nobody draws conclusions in emotional times.
Fréderic Cox On 01/03/13 12:46, "Michael Schmalle" <[email protected]> wrote: >Erik, > >Well you saw the little boy side of me as well as every one else, I'm >proud I can show feelings in an email, in this respect, I will never >consider myself a professional. > >The problem I had was with the fact we have been communicating quite >nicely and then these two commits. Putting it in New Hampshire speak, >it felt like I got a snow ball full of ice hitting my face directly. >If we would have talked a bit first at least I could have ducked >(prepared to refactor my dependent projects). > >My project is kind of NDA at the moment but completely uses the >compiler.jx platform. This is what I have been talking about "I am >working on other projects". I actually mean, I am working on other >projects that plug into THIS framework. > >So what you changed affected my project that is not going to be in >Apache at the moment. > >I guess the real reason I got upset was just the "communication" about >refactoring, I thought a month ago we had a conversation that we would >talk to each other if we were going to do anything drastic. I >understand the commit and review but, I hope we can understand with a >project like this, we should review and commit on changes dealing with >the test platform and public API. (you know what I'm talking about). > >Since you explain eloquently your reasons, I will take an hour and get >my project working again. > >BTW, did you mean to commit the SWC in the repository? > >Mike > > > >Quoting Erik de Bruin <[email protected]>: > >> 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 <[email protected]> wrote: >>> >>> >>> >>> On 2/28/13 4:22 PM, "Michael Schmalle" <[email protected]> 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 >> > >-- >Michael Schmalle - Teoti Graphix, LLC >http://www.teotigraphix.com >http://blog.teotigraphix.com >
