I understand clear as mud, that is exactly what it was to you. My
point is that sometimes when I am creating things from scratch as in
AMD, I am not going to commit it right off the bat because I don't
want to be moving files around and doing a bunch of nosensical
commits, that is the way I work.
I am doing nothing in AMD that you could break other than you changing
visitor methods or something, which I think we can both agree we
wouldn't do unless we made all the "current" tests pass. That is what
I did on a couple of my commits but, I made the tests pass.
The point of unit testing is that you can develop somethings off line
and they "shouldn't" have a direct dependency on what you are working
on for the tests or for that matter anything under a current unit
test. This is the case with the AMD and another reason I designed the
emitter and visitor framework the way I did, so it's really modular
and unobtrusive.
Anyway, the AMD is no different than what you are working on other
than the fact I need to create a temp StringBuilder that could be used
when using write() so I could replace dependencies at the end.
There is no more state than anything else, so it's what you hoped.
I am probably going to commit the rest of that code and tests in a day or two.
I am not clear on when I can get back to MXML. I am currently working
on something that is taking a bit of time. Like I said, with this
project as it stands I am more concerned about JS being compiled as
business logic first, I have said that from the beginning.
Mike
Quoting Erik de Bruin <e...@ixsoftware.nl>:
Just to clarify some stuff, since this is my "first day back on the
job after a week long sick leave which was supposed to a ski vacation"
(and I'm a bit cranky still as a result... I really shouldn't be in
public) and I need to get back up to speed on our lovely project:
You don't need to test anything, I haven't committed them yet.
Well... I need to test everything before committing, so my changes
don't break the code base... at least, that's what I was told earlier
on in the process ;-)
As far as asking about methods, what I added made sense and should have made
sense to you by them being overridable. I mean;
The aren't overridden in the code that I have access to, as it isn't
in SVN. Or I wouldn't have been able to remove them and still have the
code on my side compile and all tests pass.
Should be pretty clear they were hooks to add sources and SWCs to compile
against.
I want to say "clear as mud", but that might be a too little negative
:-) I didn't see any implementation, so I wasn't able to infer
functionality.
'Nuf said, moving on. I apologize if the above sounds defensive of
unconstructive, I am really only trying to understand.
Since we are generating JS we need context sometimes when producing stuff
like method scope, it's not a straight forward 'unit' test in this case.
I was already figuring that 'AMD' would be a bit more involved than
'goog'. The code Frank suggests for AMD isn't as straight forward a
translation from AS to JS as 'goog', as it seems to me to require a
lot more "memory/state" from the compiler. I hope I'm wrong and this
isn't the case, and you'll be soon ready to give MXML another shot. I
hope to bring Alex's FlexJS frameworks and approach to FalconJx, so we
can move forward with only one JS compiler to "worry" about :-)
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
