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
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
Erik,
Here is the misunderstanding in a nut shell.
The commit I got so upset about was mainly knee jerk but is served as
a warning to me. The ONLY time I have a problem with any type of
commit then review process is when the changes or refactoring have
to do with the frameworks (existing)
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,
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
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
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
I see your commit with MXML, where is this other changes?
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
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
Just to back up what I am saying about codegen refactor;
Look at 'org.apache.flex.compiler.tree'
and
'org.apache.flex.compiler.internal.tree'
Basically, the are saying we have a bunch of different types of
'trees' but they are all trees so each 'type' of tree gets it's own
sub package in
LOL, you told me to discuss first, commit later... which is what I'm doing.
I'm writing a big reply to your comments, just had to get this out of
the way ;-)
EdB
On Mon, Mar 4, 2013 at 10:42 PM, Michael Schmalle
apa...@teotigraphix.com wrote:
I see your commit with MXML, where is this other
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
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
13 matches
Mail list logo
