Now we're on the same page :-)
Happy coding!
EdB
On Tue, Mar 5, 2013 at 12:07 PM, Michael Schmalle
<apa...@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 <e...@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
>> <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
>>
>
> --
> 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
