You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Erik de Bruin <er...@ixsoftware.nl> on 2013/03/04 22:19:26 UTC
[FalconJx] major commit ready to go...
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
Re: [FalconJx] major commit ready to go...
Posted by Michael Schmalle <ap...@teotigraphix.com>.
I didn't tell you anything.
I asked if we could discuss changes BEFORE your even wrote anything to commit.
Mike
Quoting Erik de Bruin <er...@ixsoftware.nl>:
> LOL, you told me to discuss first, commit later... which is what I'm doing.
>
> I'm writing a big reply to your comments, just had to get this out of
> the way ;-)
>
> EdB
>
>
>
> On Mon, Mar 4, 2013 at 10:42 PM, Michael Schmalle
> <ap...@teotigraphix.com> wrote:
>> I see your commit with MXML, where is this other changes?
>>
>>
>> Mike
>>
>>
>> Quoting Erik de Bruin <er...@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
Re: [FalconJx] major commit ready to go...
Posted by Erik de Bruin <er...@ixsoftware.nl>.
LOL, you told me to discuss first, commit later... which is what I'm doing.
I'm writing a big reply to your comments, just had to get this out of
the way ;-)
EdB
On Mon, Mar 4, 2013 at 10:42 PM, Michael Schmalle
<ap...@teotigraphix.com> wrote:
> I see your commit with MXML, where is this other changes?
>
>
> Mike
>
>
> Quoting Erik de Bruin <er...@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
Re: [FalconJx] major commit ready to go...
Posted by Michael Schmalle <ap...@teotigraphix.com>.
I see your commit with MXML, where is this other changes?
Mike
Quoting Erik de Bruin <er...@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
Re: [FalconJx] major commit ready to go...
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Erik,
Here is the misunderstanding in a nut shell.
The commit I got so upset about was mainly knee jerk but is served as
a warning to me. The ONLY time I have a problem with any type of
"commit then review" process is when the changes or refactoring have
to do with the frameworks (existing) architecture.
I could care less about meddling in your affairs with everything else,
I understand that is development.
Does this make sense?
Can we get back on the level playing field now that we have always been on?
Mike
Quoting Erik de Bruin <er...@ixsoftware.nl>:
> 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
> <ap...@teotigraphix.com> wrote:
>> We did. :)
>>
>> I just wanted to see if you were reading every word I write. :)
>>
>>
>> Mike
>>
>>
>> Quoting Erik de Bruin <er...@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
>>> <ap...@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 <er...@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
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] major commit ready to go...
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Now we're on the same page :-)
Happy coding!
EdB
On Tue, Mar 5, 2013 at 12:07 PM, Michael Schmalle
<ap...@teotigraphix.com> wrote:
> Ha,
>
> Ok another language thing, I did not mean child in respect to inheritance, I
> meant child in respect to who knows about who, which sibling "might" work
> but its not exact since MXML can 'have' AS composed in it BUT AS cannot have
> MXML composed in it. This is where the parent child thing came from. AS will
> never know about MXML, MXML does know about AS.
>
>
> Mike
>
> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>
>> I will do it in a moment, but first I must ask: why do you say that
>> MXML is the 'child' of AS? It is no such thing, it exists (mostly)
>> separate from AS, all they share are some common ancestors (my now
>> infamous 'common' stuff). Let's call them brothers ;-)
>>
>> This latest commit I have lined up allows for the one brother (MXML)
>> to use the services of the other (AS), but like all siblings, they
>> don't tell each other what to do, they just each do their own thing:
>> write().
>>
>> EdB
>>
>>
>>
>> On Tue, Mar 5, 2013 at 11:49 AM, Michael Schmalle
>> <ap...@teotigraphix.com> wrote:
>>>
>>> DO IT! :)
>>>
>>> We will discuss architecture down the road when the dust settles, I just
>>> wanted to make sure the child(MXML) is not telling the parent(AS) what to
>>> do. :)
>>>
>>>
>>> Mike
>>>
>>> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>>>
>>>> Also, did you, or did you not want me to commit my latest
>>>> contribution, based on the description I gave?
>>>>
>>>> EdB
>>>>
>>>>
>>>> On Tue, Mar 5, 2013 at 11:37 AM, Erik de Bruin <er...@ixsoftware.nl>
>>>> wrote:
>>>>>
>>>>>
>>>>> 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
>>>>> <ap...@teotigraphix.com> wrote:
>>>>>>
>>>>>>
>>>>>> We did. :)
>>>>>>
>>>>>> I just wanted to see if you were reading every word I write. :)
>>>>>>
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>> Quoting Erik de Bruin <er...@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
>>>>>>> <ap...@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 <er...@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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
Re: [FalconJx] major commit ready to go...
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Ha,
Ok another language thing, I did not mean child in respect to
inheritance, I meant child in respect to who knows about who, which
sibling "might" work but its not exact since MXML can 'have' AS
composed in it BUT AS cannot have MXML composed in it. This is where
the parent child thing came from. AS will never know about MXML, MXML
does know about AS.
Mike
Quoting Erik de Bruin <er...@ixsoftware.nl>:
> I will do it in a moment, but first I must ask: why do you say that
> MXML is the 'child' of AS? It is no such thing, it exists (mostly)
> separate from AS, all they share are some common ancestors (my now
> infamous 'common' stuff). Let's call them brothers ;-)
>
> This latest commit I have lined up allows for the one brother (MXML)
> to use the services of the other (AS), but like all siblings, they
> don't tell each other what to do, they just each do their own thing:
> write().
>
> EdB
>
>
>
> On Tue, Mar 5, 2013 at 11:49 AM, Michael Schmalle
> <ap...@teotigraphix.com> wrote:
>> DO IT! :)
>>
>> We will discuss architecture down the road when the dust settles, I just
>> wanted to make sure the child(MXML) is not telling the parent(AS) what to
>> do. :)
>>
>>
>> Mike
>>
>> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>>
>>> Also, did you, or did you not want me to commit my latest
>>> contribution, based on the description I gave?
>>>
>>> EdB
>>>
>>>
>>> On Tue, Mar 5, 2013 at 11:37 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>>>>
>>>> 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
>>>> <ap...@teotigraphix.com> wrote:
>>>>>
>>>>> We did. :)
>>>>>
>>>>> I just wanted to see if you were reading every word I write. :)
>>>>>
>>>>>
>>>>> Mike
>>>>>
>>>>>
>>>>> Quoting Erik de Bruin <er...@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
>>>>>> <ap...@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 <er...@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
>>>
>>>
>>>
>>>
>>> --
>>> 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
Re: [FalconJx] major commit ready to go...
Posted by Erik de Bruin <er...@ixsoftware.nl>.
I will do it in a moment, but first I must ask: why do you say that
MXML is the 'child' of AS? It is no such thing, it exists (mostly)
separate from AS, all they share are some common ancestors (my now
infamous 'common' stuff). Let's call them brothers ;-)
This latest commit I have lined up allows for the one brother (MXML)
to use the services of the other (AS), but like all siblings, they
don't tell each other what to do, they just each do their own thing:
write().
EdB
On Tue, Mar 5, 2013 at 11:49 AM, Michael Schmalle
<ap...@teotigraphix.com> wrote:
> DO IT! :)
>
> We will discuss architecture down the road when the dust settles, I just
> wanted to make sure the child(MXML) is not telling the parent(AS) what to
> do. :)
>
>
> Mike
>
> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>
>> Also, did you, or did you not want me to commit my latest
>> contribution, based on the description I gave?
>>
>> EdB
>>
>>
>> On Tue, Mar 5, 2013 at 11:37 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>>>
>>> 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
>>> <ap...@teotigraphix.com> wrote:
>>>>
>>>> We did. :)
>>>>
>>>> I just wanted to see if you were reading every word I write. :)
>>>>
>>>>
>>>> Mike
>>>>
>>>>
>>>> Quoting Erik de Bruin <er...@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
>>>>> <ap...@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 <er...@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
>>
>>
>>
>>
>> --
>> 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
Re: [FalconJx] major commit ready to go...
Posted by Michael Schmalle <ap...@teotigraphix.com>.
DO IT! :)
We will discuss architecture down the road when the dust settles, I
just wanted to make sure the child(MXML) is not telling the parent(AS)
what to do. :)
Mike
Quoting Erik de Bruin <er...@ixsoftware.nl>:
> Also, did you, or did you not want me to commit my latest
> contribution, based on the description I gave?
>
> EdB
>
>
> On Tue, Mar 5, 2013 at 11:37 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>> 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
>> <ap...@teotigraphix.com> wrote:
>>> We did. :)
>>>
>>> I just wanted to see if you were reading every word I write. :)
>>>
>>>
>>> Mike
>>>
>>>
>>> Quoting Erik de Bruin <er...@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
>>>> <ap...@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 <er...@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
>
>
>
> --
> 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] major commit ready to go...
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Also, did you, or did you not want me to commit my latest
contribution, based on the description I gave?
EdB
On Tue, Mar 5, 2013 at 11:37 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> 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
> <ap...@teotigraphix.com> wrote:
>> We did. :)
>>
>> I just wanted to see if you were reading every word I write. :)
>>
>>
>> Mike
>>
>>
>> Quoting Erik de Bruin <er...@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
>>> <ap...@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 <er...@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
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJx] major commit ready to go...
Posted by Erik de Bruin <er...@ixsoftware.nl>.
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
<ap...@teotigraphix.com> wrote:
> We did. :)
>
> I just wanted to see if you were reading every word I write. :)
>
>
> Mike
>
>
> Quoting Erik de Bruin <er...@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
>> <ap...@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 <er...@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
Re: [FalconJx] major commit ready to go...
Posted by Michael Schmalle <ap...@teotigraphix.com>.
We did. :)
I just wanted to see if you were reading every word I write. :)
Mike
Quoting Erik de Bruin <er...@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
> <ap...@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 <er...@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
Re: [FalconJx] major commit ready to go...
Posted by Erik de Bruin <er...@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
<ap...@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 <er...@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
Re: [FalconJx] major commit ready to go...
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Just to back up what I am saying about codegen refactor;
Look at 'org.apache.flex.compiler.tree'
and
'org.apache.flex.compiler.internal.tree'
Basically, the are saying we have a bunch of different types of
'trees' but they are all trees so each 'type' of tree gets it's own
sub package in tree. This is what I am proposing for codegen. We have
a bunch of different 'types' of codegen, but they are all codegen so
each type of codegen gets its own sub package.
You see the symmetry here?, You said you like symmetry, so there you go.
We can have the 'common' API for codegen in the root of codegen so you
can see the 'common' API by just opening up codegen but at the same
time see the different types of code gen subpackages, as, js, mxml.
By using this layout, none of the API is spread around in duplicate
package naming.
I will change this if you agree, if you don't agree I guess we will
have to vote on it or something because this seriously needs to get
out of the way before any more development is done. (we need to know
you and I are on a level commit base)
Mike
Quoting Michael Schmalle <ap...@teotigraphix.com>:
> 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 <er...@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
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] major commit ready to go...
Posted by Michael Schmalle <ap...@teotigraphix.com>.
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 <er...@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
Re: [FalconJx] major commit ready to go...
Posted by Erik de Bruin <er...@ixsoftware.nl>.
We're all good. MXML only uses AS, no changes were made - nor am I
planning to make any - to the AS implementation, apart from a minor
refactoring of BlockWalker and BlockVisitor to allow for a shared
ancestor.
EdB
On Mon, Mar 4, 2013 at 10:26 PM, Michael Schmalle
<ap...@teotigraphix.com> wrote:
> Well,
>
> I purposely did not want anything ActionScript tied to MXML. There was a way
> to invoke the walker within the MXML visitor(... sounds like you might have
> done this).
>
> I guess this is what I get for not finishing it to a point of working. Email
> is to hard to discuss something like this where you have already changed
> things.
>
> I just have one blunt question, have you at all tied the AS implementation
> to the MXML, I don't care the other way around but, if you changed any of
> the AS visitor implementation that is coupled to the MXML I think its a bad
> design and needs to be thought about, if not, great then.
>
> Mike
>
>
>
> Quoting Erik de Bruin <er...@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
Re: [FalconJx] major commit ready to go...
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Well,
I purposely did not want anything ActionScript tied to MXML. There was
a way to invoke the walker within the MXML visitor(... sounds like you
might have done this).
I guess this is what I get for not finishing it to a point of working.
Email is to hard to discuss something like this where you have already
changed things.
I just have one blunt question, have you at all tied the AS
implementation to the MXML, I don't care the other way around but, if
you changed any of the AS visitor implementation that is coupled to
the MXML I think its a bad design and needs to be thought about, if
not, great then.
Mike
Quoting Erik de Bruin <er...@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