Quoting Erik de Bruin <e...@ixsoftware.nl>:
Another one popped into my head just now: I have a gut feeling there
is a bit of circular logic going on in the whole 'backend',
'blockwalker' and 'emitter' construct. More specifically in the way
the references to them are passed around as arguments in the
constructors for the various classes. But I can't wrap around it well
enough to figure out whether it's wrong and if so, what might be done
about it. Don't get me wrong, it works well, it's just that it somehow
isn't "elegant". And that's in no way a comment on the effectiveness
or quality of your code, just something I thought I'd share and see
what you think.
Actually I think it works fine. The problem you are facing is with the
MXML emitter I am sure. This adds complexity to what you are trying to
accomplish and it is circular from the perspective of using AS within
MXML.
There is a buffer writer(output stream), a writer, a visitor and emitter.
Each one takes a dependency of its parent. Trust me, if there is a
child that knows about its parent I am blind. Like I said, the block
walker is a visitor and the emitter is a visitor. You cannot escape
the fact there is recursion.
If you can think of a more elegant way to set it up, by all means
write a prototype. Remember, I wrote this with an atom bomb under me
and lighting in the sky, there may be parts that could be logicalized.
I have another full compiler in Randori that I am going to use as a
proof of concept with compiler plugins and my ASDoc compiler I wrote.
So I guess we both can experiment, we can agree to leave the core
alone for the time being.
EdB
On Wed, Mar 27, 2013 at 7:41 PM, Erik de Bruin <e...@ixsoftware.nl> wrote:
Mike,
Just kidding ;-)
I'm really happy with FalconJx, once you get to know it it's a
pleasure to work with. I hope my last commits didn't give you any
additional work in your other projects? I did my best to leave all the
APIs alone.
There are plenty of TODOs in the code, and I would also like to
suggest some kind of code review or something (I'm not used to working
in groups, but that seems like a nice thing to do), since I've been
piling on stuff. I did my best to keep everything clean and in line
with the spirit of the rest of the code, but there are some areas
where I'd like to have a second opinion. Like with the code that is
copied between the DOC and JS emitters, seems there might be room for
improvement there. Also of note is the way I've implemented the AS
emitting within the MXML emitter, not really sure if I did the right
thing there. And finally (not really, but this is all I can think of
for now, after the marathon hacking I did today) there is the whole
"programming to interfaces, not implementations" part that we nearly
adhere to, but not quite, we might have another look at that as well.
EdB
On Wed, Mar 27, 2013 at 7:33 PM, Michael Schmalle
<apa...@teotigraphix.com> wrote:
No thats not what I meant.
I am saying with the Randori project compiler, I have not had to touch the
core framework for weeks and it is compiling 1000's of lines of code. And
application code now.
What I meant to say was, the design keeps people in the correct spaces. :)
Note; I AM SURE there are as3 bugs coming, its just nice not
having to chase
them right now.
Mike
Quoting Erik de Bruin <e...@ixsoftware.nl>:
All I can say is its easy to fix things in the emitters. :)
Thanks, I feel SO special now...
:-P
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
--
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
