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
