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
<apa...@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 <e...@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 <e...@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
>>> <apa...@teotigraphix.com> wrote:
>>>>
>>>> We did. :)
>>>>
>>>> I just wanted to see if you were reading every word I write. :)
>>>>
>>>>
>>>> Mike
>>>>
>>>>
>>>> Quoting Erik de Bruin <e...@ixsoftware.nl>:
>>>>
>>>>> It's re-renamed (de-named?).
>>>>>
>>>>> About 'common', I tried to explain that might be a misnomer due to me
>>>>> not being a native English speaker.
>>>>>
>>>>> As stated before, I complete stand behind what you say about moving
>>>>> everything (as, js and mxml) into one 'codegen', 'driver' and
>>>>> 'visitor' package. I just thought we had agreed to postpone such a
>>>>> major refactor until some point in the future?
>>>>>
>>>>> EdB
>>>>>
>>>>>
>>>>> On Tue, Mar 5, 2013 at 1:16 AM, Michael Schmalle
>>>>> <apa...@teotigraphix.com> wrote:
>>>>>>
>>>>>>
>>>>>> Erik;
>>>>>>
>>>>>>> renamed IASNodeStrategy to INodeStrategy
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I disagree, please rename that interface back to IASNodeStrategy.
>>>>>>
>>>>>> The only method it has is handle(IASNode node), notice the IASNode. It
>>>>>> is
>>>>>> a
>>>>>> IASNode handler strategy.
>>>>>>
>>>>>> Can we please be a little more pragmatic at this refactoring and
>>>>>> renaming? I
>>>>>> don't understand what compelled you to want to rename that interface.
>>>>>>
>>>>>> I'm really not liking this 'common' folder at all. I really believe
>>>>>> common
>>>>>> API belongs in it's own package, not sub packages of a common
>>>>>> directory.
>>>>>> Look at how the falcon framework is laid out, they do not abuse the
>>>>>> common
>>>>>> directory.
>>>>>>
>>>>>> Putting codegen and things on a common directory when there is already
>>>>>> a
>>>>>> codegen directory is redundant and confusing for others in the future.
>>>>>> That
>>>>>> being said, I said it was MY mistake not making a codegen and driver
>>>>>> directory in compiler. If you want to refactor, do it right and make a
>>>>>> codegen, driver in the compiler, then move the 'as', 'js' and 'mxml'
>>>>>> into
>>>>>> the codegen package and axe the common package.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>> Quoting Erik de Bruin <e...@ixsoftware.nl>:
>>>>>>
>>>>>>> Mike et al.,
>>>>>>>
>>>>>>> I have a reasonably big commit lined up. To make AS embedded in MXML
>>>>>>> work without doing duplicate work, I figured I could best use the
>>>>>>> existing ASEmitter and subclases. To make this work, I needed to add
>>>>>>> an ASBlockWalker to the MXMLBlockWalker and make adjustments to some
>>>>>>> existing code (refactoring of interfaces and method signatures,
>>>>>>> mostly). I was able to keep most of this trickery limited to MXML
>>>>>>> classes, but I needed to make some changes to these 'common' and AS
>>>>>>> classes:
>>>>>>>
>>>>>>> - renamed IASNodeStrategy to INodeStrategy, as it is now 'common' and
>>>>>>> used by both AS and MXML; this renaming touches 'a few' other
>>>>>>> classes,
>>>>>>> like IJSEmitter and the classes in
>>>>>>> 'org.apache.flex.compiler.internal.as.codegen'
>>>>>>> - created IBlockVisitor and IBlockWalker as 'common' interfaces
>>>>>>> - refactored IASBlockVisitor and IASBlockWalker to extend these new
>>>>>>> interfaces
>>>>>>>
>>>>>>> All tests pass (I even managed to get a few more done for FlexJS) and
>>>>>>> the road ahead seems clear...
>>>>>>>
>>>>>>> Let me know if any of this will break anything beyond repair - or at
>>>>>>> least beyond a little time spend adjusting code to the new - if I
>>>>>>> commit these changes,
>>>>>>>
>>>>>>> EdB
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Ix Multimedia Software
>>>>>>>
>>>>>>> Jan Luykenstraat 27
>>>>>>> 3521 VB Utrecht
>>>>>>>
>>>>>>> T. 06-51952295
>>>>>>> I. www.ixsoftware.nl
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Michael Schmalle - Teoti Graphix, LLC
>>>>>> http://www.teotigraphix.com
>>>>>> http://blog.teotigraphix.com
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Ix Multimedia Software
>>>>>
>>>>> Jan Luykenstraat 27
>>>>> 3521 VB Utrecht
>>>>>
>>>>> T. 06-51952295
>>>>> I. www.ixsoftware.nl
>>>>>
>>>>
>>>> --
>>>> Michael Schmalle - Teoti Graphix, LLC
>>>> http://www.teotigraphix.com
>>>> http://blog.teotigraphix.com
>>>>
>>>
>>>
>>>
>>> --
>>> Ix Multimedia Software
>>>
>>> Jan Luykenstraat 27
>>> 3521 VB Utrecht
>>>
>>> T. 06-51952295
>>> I. www.ixsoftware.nl
>>
>>
>>
>>
>> --
>> 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
