Mike, I'm confused. I'm sure it's me (being a foreigner and all), but I don't understand what you're asking of me...
I did a big commit 'solo', it nearly was vetoed. The suggestion was I talk about what I plan to change before actually committing next time I needed to make changes that might influence other's code. I did (this thread), but now you seem to be asking me to discuss what I'm going to do even BEFORE I actually write code, locally? I'm not sure what your process is, but mine generally starts with a goal ("enable js output from MXML"), after which if tinker with the code until it works. This may or may not involve dead ends, reverts or do-overs. Mostly, what I thought might work doesn't and what ends up working is not at all what I though it might be. When the code works, I clean it up, re-format it, run the tests one more time and commit. I'm not sure how I can discuss changes to the code before I touch the code. I can, however, discuss what I'll be working on, which I thought I did... As the original contributor of the FalconJx code, in my mind you are the de-facto project lead. I therefore defer to your suggestions, most of the time ;-) I don't mind that at all, as long as we work as a team. I'm trying to understand what you think is the best way to cooperate and how I can best fit that into my work. Please be patient and maybe explain things "like I'm a 5 year old", just so I understand what it is you're expecting of me. Thanks, EdB On Tue, Mar 5, 2013 at 10:56 AM, Michael Schmalle <apa...@teotigraphix.com> wrote: > We did. :) > > I just wanted to see if you were reading every word I write. :) > > > Mike > > > Quoting Erik de Bruin <e...@ixsoftware.nl>: > >> It's re-renamed (de-named?). >> >> About 'common', I tried to explain that might be a misnomer due to me >> not being a native English speaker. >> >> As stated before, I complete stand behind what you say about moving >> everything (as, js and mxml) into one 'codegen', 'driver' and >> 'visitor' package. I just thought we had agreed to postpone such a >> major refactor until some point in the future? >> >> EdB >> >> >> On Tue, Mar 5, 2013 at 1:16 AM, Michael Schmalle >> <apa...@teotigraphix.com> wrote: >>> >>> Erik; >>> >>>> renamed IASNodeStrategy to INodeStrategy >>> >>> >>> >>> I disagree, please rename that interface back to IASNodeStrategy. >>> >>> The only method it has is handle(IASNode node), notice the IASNode. It is >>> a >>> IASNode handler strategy. >>> >>> Can we please be a little more pragmatic at this refactoring and >>> renaming? I >>> don't understand what compelled you to want to rename that interface. >>> >>> I'm really not liking this 'common' folder at all. I really believe >>> common >>> API belongs in it's own package, not sub packages of a common directory. >>> Look at how the falcon framework is laid out, they do not abuse the >>> common >>> directory. >>> >>> Putting codegen and things on a common directory when there is already a >>> codegen directory is redundant and confusing for others in the future. >>> That >>> being said, I said it was MY mistake not making a codegen and driver >>> directory in compiler. If you want to refactor, do it right and make a >>> codegen, driver in the compiler, then move the 'as', 'js' and 'mxml' into >>> the codegen package and axe the common package. >>> >>> >>> >>> Mike >>> >>> >>> Quoting Erik de Bruin <e...@ixsoftware.nl>: >>> >>>> Mike et al., >>>> >>>> I have a reasonably big commit lined up. To make AS embedded in MXML >>>> work without doing duplicate work, I figured I could best use the >>>> existing ASEmitter and subclases. To make this work, I needed to add >>>> an ASBlockWalker to the MXMLBlockWalker and make adjustments to some >>>> existing code (refactoring of interfaces and method signatures, >>>> mostly). I was able to keep most of this trickery limited to MXML >>>> classes, but I needed to make some changes to these 'common' and AS >>>> classes: >>>> >>>> - renamed IASNodeStrategy to INodeStrategy, as it is now 'common' and >>>> used by both AS and MXML; this renaming touches 'a few' other classes, >>>> like IJSEmitter and the classes in >>>> 'org.apache.flex.compiler.internal.as.codegen' >>>> - created IBlockVisitor and IBlockWalker as 'common' interfaces >>>> - refactored IASBlockVisitor and IASBlockWalker to extend these new >>>> interfaces >>>> >>>> All tests pass (I even managed to get a few more done for FlexJS) and >>>> the road ahead seems clear... >>>> >>>> Let me know if any of this will break anything beyond repair - or at >>>> least beyond a little time spend adjusting code to the new - if I >>>> commit these changes, >>>> >>>> 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 >>> >> >> >> >> -- >> 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 > -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl