You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Michael Schmalle <ap...@teotigraphix.com> on 2013/02/28 23:45:40 UTC
[FalconJx] Refactoring packages
Erik,
I was wondering if we could agree, that before we move packages around
that we could have a discussion first about the implications? I almost
had a heart attack looking at the last svn update log. I seriously
don't want to veto any commits but the farther we go with the
development of the core visitor framework, the more code that is being
built on it, specifically a couple projects of mine.
Major refactors can be very disruptive.
What is your strategy with MXML? Your implementation of vanilla, your
are creating instances with the 'new' operator?
Are you planning on implementing Alex's data structures?
Mike
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] Refactoring packages
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Quoting Erik de Bruin <er...@ixsoftware.nl>:
> Mike,
>
>> 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
>
> Yes, mea culpa on the communication.
>
>> 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.
>
> As a mental exercise, purely out of curiosity - as I just promised "it
> won't happen again" - would you try to veto changes to an Apache Flex
> project when those changes negatively affect a private, non-open
> source project?
No, I would not, I am sending an email right now that would explain a
veto on this commit. I would never veto something based on something
you couldn't see. BTW what I am working on WILL be 100% open source
when it is released...
> In light of our newly re-found communication (:-)), which parts of
> this framework do your private projects rely on? Can I hack away at
> the MXML stuff without bothering you too much? And, maybe more
> importantly, will you be donating improvements you make to your local
> copy of the framework back to Apache and if so, how might those
> improvements influence the code that's based upon the current version
> of the framework?
Erik, this had nothing to do with my project It had to do with I
disagreed with your changes(some of them). Having an external project
that uses the framework amplified my reason for disagreement, but I
still would have disagreed without that project.
There is no local copy! The framework is solid man, I am up to date on
all my commits with falcon.jx. I am not developing anything in secret
regarding the actual falcon.jx project.
>> BTW, did you mean to commit the SWC in the repository?
>
> I meant to commit all the FlexJS files and dependencies for the
> moment, until I have broken it down into their separate pieces and
> written test for all of them. I didn't however realize that the swc
> was a binary, thanks for pointing that out. I'll remove it from the
> repo on my next commit.
>
> Now, moving forward: I'll be doing a lot of work on any file that has
> MXML in it's name. Do you foresee any problems with that? I might also
> need to make minor modifications to some of the supporting files. When
> do you consider a change worthy of discussion?
No, go for it, see above, I have no "hidden" branch of falcon.jx.
Mike
> 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
Re: [FalconJx] Refactoring packages
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Mike,
> 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
Yes, mea culpa on the communication.
> 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.
As a mental exercise, purely out of curiosity - as I just promised "it
won't happen again" - would you try to veto changes to an Apache Flex
project when those changes negatively affect a private, non-open
source project?
In light of our newly re-found communication (:-)), which parts of
this framework do your private projects rely on? Can I hack away at
the MXML stuff without bothering you too much? And, maybe more
importantly, will you be donating improvements you make to your local
copy of the framework back to Apache and if so, how might those
improvements influence the code that's based upon the current version
of the framework?
> BTW, did you mean to commit the SWC in the repository?
I meant to commit all the FlexJS files and dependencies for the
moment, until I have broken it down into their separate pieces and
written test for all of them. I didn't however realize that the swc
was a binary, thanks for pointing that out. I'll remove it from the
repo on my next commit.
Now, moving forward: I'll be doing a lot of work on any file that has
MXML in it's name. Do you foresee any problems with that? I might also
need to make minor modifications to some of the supporting files. When
do you consider a change worthy of discussion?
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJx] Refactoring packages
Posted by Fréderic Cox <co...@gmail.com>.
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" <ap...@teotigraphix.com> 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 <er...@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 <ah...@adobe.com> wrote:
>>>
>>>
>>>
>>> On 2/28/13 4:22 PM, "Michael Schmalle" <ap...@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
>>
>
>--
>Michael Schmalle - Teoti Graphix, LLC
>http://www.teotigraphix.com
>http://blog.teotigraphix.com
>
Re: [FalconJx] Refactoring packages
Posted by Michael Schmalle <ap...@teotigraphix.com>.
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 <er...@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 <ah...@adobe.com> wrote:
>>
>>
>>
>> On 2/28/13 4:22 PM, "Michael Schmalle" <ap...@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
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] Refactoring packages
Posted by Erik de Bruin <er...@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 <ah...@adobe.com> wrote:
>
>
>
> On 2/28/13 4:22 PM, "Michael Schmalle" <ap...@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
Re: [FalconJx] Refactoring packages
Posted by Michael Schmalle <ap...@teotigraphix.com>.
But I'm glad I wasted 2+ hours of my night on commit and review with a
project that is still trying to get off the ground.
I have to be honest, this won't happen to much with me. Dealing with a
project like falconjx with A LOT of moving parts, I cannot work like
this.
Mike
Quoting Michael Schmalle <ap...@teotigraphix.com>:
> Also,
>
> He should revert commit 1451144 because he put a binary SWC in the
> repo which is a no no, and well dam I would just like some input on
> this refactoring stuff before it changes since this project is still
> developing.
>
> Commit and review could end up be a serious setback with this
> project if it happens this way.
>
> Mike
>
>
> Quoting Michael Schmalle <ap...@teotigraphix.com>:
>
>>
>> I want 1451312 reverted
>>
>> "Another major refactoring, but..."
>>
>> Right, WAY TO MAJOR. This was to much to change in one commit.
>>
>> Mike
>>
>>
>>
>> Quoting Justin Mclean <ju...@classsoftware.com>:
>>
>>> Hi,
>>>
>>> I not been following the exact changes here, but any changes to
>>> SVN can be reverted if need be and any committer can veto a check
>>> in if they feel there's a valid reason for doing so. That's part
>>> of the commit then review process we have.
>>>
>>> Can you discuss the changes made on list and come up with a way to
>>> solve this?
>>>
>>> Thanks,
>>> Justin
>>
>> --
>> Michael Schmalle - Teoti Graphix, LLC
>> http://www.teotigraphix.com
>> http://blog.teotigraphix.com
>>
>>
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] Refactoring packages
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Also,
He should revert commit 1451144 because he put a binary SWC in the
repo which is a no no, and well dam I would just like some input on
this refactoring stuff before it changes since this project is still
developing.
Commit and review could end up be a serious setback with this project
if it happens this way.
Mike
Quoting Michael Schmalle <ap...@teotigraphix.com>:
>
> I want 1451312 reverted
>
> "Another major refactoring, but..."
>
> Right, WAY TO MAJOR. This was to much to change in one commit.
>
> Mike
>
>
>
> Quoting Justin Mclean <ju...@classsoftware.com>:
>
>> Hi,
>>
>> I not been following the exact changes here, but any changes to SVN
>> can be reverted if need be and any committer can veto a check in if
>> they feel there's a valid reason for doing so. That's part of the
>> commit then review process we have.
>>
>> Can you discuss the changes made on list and come up with a way to
>> solve this?
>>
>> Thanks,
>> Justin
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] Refactoring packages
Posted by Alex Harui <ah...@adobe.com>.
On 2/28/13 4:22 PM, "Michael Schmalle" <ap...@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
Re: [FalconJx] Refactoring packages
Posted by Michael Schmalle <ap...@teotigraphix.com>.
I want 1451312 reverted
"Another major refactoring, but..."
Right, WAY TO MAJOR. This was to much to change in one commit.
Mike
Quoting Justin Mclean <ju...@classsoftware.com>:
> Hi,
>
> I not been following the exact changes here, but any changes to SVN
> can be reverted if need be and any committer can veto a check in if
> they feel there's a valid reason for doing so. That's part of the
> commit then review process we have.
>
> Can you discuss the changes made on list and come up with a way to
> solve this?
>
> Thanks,
> Justin
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] Refactoring packages
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
I not been following the exact changes here, but any changes to SVN can be reverted if need be and any committer can veto a check in if they feel there's a valid reason for doing so. That's part of the commit then review process we have.
Can you discuss the changes made on list and come up with a way to solve this?
Thanks,
Justin
Re: [FalconJx] Refactoring packages
Posted by Alex Harui <ah...@adobe.com>.
On 2/28/13 3:54 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
> Quoting Alex Harui <ah...@adobe.com>:
>
>>
>>
>>
>> On 2/28/13 3:38 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>>
>>> Ok,
>>>
>>> Going to reply again.
>>>
>>> It just keeps getting better as I look. You know I understand this is
>>> a Apache but, if you can just go into this code and just change crap
>>> like you did without at least talking on list first, I'm just going to
>>> fork my code on GIT and leave Apache.
>> Then veto the commit and Erik will revert. That is also Apache, IMO.
>> Instead of waiting for you to respond to a pre-check-in discussion, it can
>> be more efficient to check in code because then there is no confusion of
>> words describing what changed, you can see the code changes.
>
> I understand this but, I was under the impression that Erik and I were
> working together(team) and he should know I watch my mail everyday,
> this is what partnership is.
There have been plenty of times I thought I was doing something that would
help everybody and was wrong. These kinds of things happen.
>
> If I have overreacted its because I thought Erik and I had an "understanding".
>
> Well I would like a revert, I want to talk about these changes first.
Grab the commit email and reply with a -1 and a technical reason why.
Package names are a bit subjective. Breaking a big check-in you are
planning is legitimate.
>
> I will not take back anything I have said, I seriously felt weird
> about this commit. I have tried to offer this project as much optimism
> as possible, I do not want to look like someone that is trying to
> control something either, it's the communication about "refactoring"
> that I am upset about.
No need to take anything back. We'll all get mad at each other at some
point.
>
> Mike
>
>
>> I'm sure if Erik felt it was going to be controversial he would have asked
>> first. Sometimes we're going to unknowingly step on each other's toes and
>> that's why we have commit reviews.
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJx] Refactoring packages
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Quoting Alex Harui <ah...@adobe.com>:
>
>
>
> On 2/28/13 3:38 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
>> Ok,
>>
>> Going to reply again.
>>
>> It just keeps getting better as I look. You know I understand this is
>> a Apache but, if you can just go into this code and just change crap
>> like you did without at least talking on list first, I'm just going to
>> fork my code on GIT and leave Apache.
> Then veto the commit and Erik will revert. That is also Apache, IMO.
> Instead of waiting for you to respond to a pre-check-in discussion, it can
> be more efficient to check in code because then there is no confusion of
> words describing what changed, you can see the code changes.
I understand this but, I was under the impression that Erik and I were
working together(team) and he should know I watch my mail everyday,
this is what partnership is.
If I have overreacted its because I thought Erik and I had an "understanding".
Well I would like a revert, I want to talk about these changes first.
I will not take back anything I have said, I seriously felt weird
about this commit. I have tried to offer this project as much optimism
as possible, I do not want to look like someone that is trying to
control something either, it's the communication about "refactoring"
that I am upset about.
Mike
> I'm sure if Erik felt it was going to be controversial he would have asked
> first. Sometimes we're going to unknowingly step on each other's toes and
> that's why we have commit reviews.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] Refactoring packages
Posted by Alex Harui <ah...@adobe.com>.
On 2/28/13 3:38 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
> Ok,
>
> Going to reply again.
>
> It just keeps getting better as I look. You know I understand this is
> a Apache but, if you can just go into this code and just change crap
> like you did without at least talking on list first, I'm just going to
> fork my code on GIT and leave Apache.
Then veto the commit and Erik will revert. That is also Apache, IMO.
Instead of waiting for you to respond to a pre-check-in discussion, it can
be more efficient to check in code because then there is no confusion of
words describing what changed, you can see the code changes.
I'm sure if Erik felt it was going to be controversial he would have asked
first. Sometimes we're going to unknowingly step on each other's toes and
that's why we have commit reviews.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJx] Refactoring packages
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Ok,
Going to reply again.
It just keeps getting better as I look. You know I understand this is
a Apache but, if you can just go into this code and just change crap
like you did without at least talking on list first, I'm just going to
fork my code on GIT and leave Apache.
This is crap Erik, yeah I'm upset. The amount of changes you made
without consulting the "list" is not the way I would do it. Adding
stuff is different, but when you just go in and completely refactor
MAJOR stuff it makes me feel like I'm just this guy that is invisible
to you.
Sorry about this attitude but I have one right now. I would never have
done this to community code without talking about it first but, that
is just me.
Mike
Quoting Michael Schmalle <ap...@teotigraphix.com>:
> I'm going to reply to my own post here.
>
> I disagree with where you put Emitter.
>
> Until we support more parsed languages... Emitter belongs in
> internal.as.codegen.
>
> I don not think common packages should have sub packages. If you
> want a driver package put it under compiler. If you want a common
> codegen, put it under compiler.
>
> Your changes in this commit caused 136 errors in my project's impl
> and test suite.
>
> If we can't talk about these massive types of changes first, I will
> veto the commit and ask you to revert, then we can talk.
>
> We still need to decide about these changes because I don't agree
> with the above stated.
>
> Mike
>
>
>
> Quoting Michael Schmalle <ap...@teotigraphix.com>:
>
>>
>> Erik,
>>
>> I was wondering if we could agree, that before we move packages
>> around that we could have a discussion first about the
>> implications? I almost had a heart attack looking at the last svn
>> update log. I seriously don't want to veto any commits but the
>> farther we go with the development of the core visitor framework,
>> the more code that is being built on it, specifically a couple
>> projects of mine.
>>
>> Major refactors can be very disruptive.
>>
>> What is your strategy with MXML? Your implementation of vanilla,
>> your are creating instances with the 'new' operator?
>>
>> Are you planning on implementing Alex's data structures?
>>
>> Mike
>>
>>
>> --
>> Michael Schmalle - Teoti Graphix, LLC
>> http://www.teotigraphix.com
>> http://blog.teotigraphix.com
>>
>>
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] Refactoring packages
Posted by Michael Schmalle <ap...@teotigraphix.com>.
I'm going to reply to my own post here.
I disagree with where you put Emitter.
Until we support more parsed languages... Emitter belongs in
internal.as.codegen.
I don not think common packages should have sub packages. If you want
a driver package put it under compiler. If you want a common codegen,
put it under compiler.
Your changes in this commit caused 136 errors in my project's impl and
test suite.
If we can't talk about these massive types of changes first, I will
veto the commit and ask you to revert, then we can talk.
We still need to decide about these changes because I don't agree with
the above stated.
Mike
Quoting Michael Schmalle <ap...@teotigraphix.com>:
>
> Erik,
>
> I was wondering if we could agree, that before we move packages
> around that we could have a discussion first about the implications?
> I almost had a heart attack looking at the last svn update log. I
> seriously don't want to veto any commits but the farther we go with
> the development of the core visitor framework, the more code that is
> being built on it, specifically a couple projects of mine.
>
> Major refactors can be very disruptive.
>
> What is your strategy with MXML? Your implementation of vanilla,
> your are creating instances with the 'new' operator?
>
> Are you planning on implementing Alex's data structures?
>
> Mike
>
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com