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
<apa...@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 <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

Reply via email to