flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fr├ęderic Cox <coxfrede...@gmail.com>
Subject Re: [FalconJx] Refactoring packages
Date Fri, 01 Mar 2013 11:49:11 GMT
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" <apache@teotigraphix.com> wrote:

>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?
>Quoting Erik de Bruin <erik@ixsoftware.nl>:
>> 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 <aharui@adobe.com> wrote:
>>> On 2/28/13 4:22 PM, "Michael Schmalle" <apache@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
>>> with the refactoring?  If the problem is that it made it hard for you
>>> contribute to the code because you have to figure out where everything
>>> to, that is a concern worth voicing, but if the refactoring has
>>> 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

View raw message