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
