Oh yeah,
As far as the "AS3" output you have in the graph example, that will
not be possible with the current incarnation with Falcon.
Unfortunately, the the parser does not keep the whitespace tokens or
really any token information at all.
When a parser node is created the line and column numbers are saved
from the token but the token is discarded and there is no real way I
can update the parser to keep the original code. I mentioned this to
Gordon a while ago and he did say that eventually he wanted to have
Falcon be able to saved the tokens and white space tokens.
I did have a radical thought that there could be a two pass parse with
the tokenizer that would save the tokens into a map with location and
some type of logic within the traverse could extract the correct
tokens in between parser nodes using the line and column information.
But this is not at all a priority for me but would like to experiment
sometime, maybe that is something you could try someday when you
understand the parser abit more! :)
Mike
Quoting Frank Wienberg <fr...@jangaroo.net>:
Hi Mike,
great to hear you are well again and have some time to spend on the AMD
approach!
On Mon, Feb 4, 2013 at 12:56 PM, Michael Schmalle
<apa...@teotigraphix.com>wrote:
Frank,
I am starting on this and you have confused me starting off. The wiki
entry under the header of "Implementation Solution" does NOT look at all
the same as your A.js production in the 'as-js-runtime-prototype' source
code.
What am I missing? Which is the correct way you want this output. I
thought you put the GIT repo up so I could see an implementation using
classes and interfaces together.
I set up the as-js-runtime-prototype first, before I started implementing
this solution in the Jangaroo compiler. As always, when I implement (even
my own) specifications, I find flaws and missing aspects or things you
could do more cleverly.
So *after* implementing the AMD approach with Jangaroo 3, I wrote down the
final design on the Wiki page. I tried to include sufficient concrete code
examples, but I can totally see that an updated and Wiki-page-consistent
as-js-runtime-prototype would help, too.
Please stand by for the latest code, and please for the time being, use the
Wiki page as reference.
Sorry for the confusion!
I will be honest, when we were talking about line numbers, I thought you
were talking about MATCHING AS Exactly but, in your example you are just
referencing them on the expression statements correct?
Yes, the source line number references in the generated code are a way to
get around some indirections Jangaroo needs to get each line of generated
code into exactly the same line as the source code. This is the difference
between the solution I implemented for Jangaroo and the solution I propose
for FalconJx. If you take Jangaroo 3 compilation results like the ones from
the Open Flash Chart
demo<http://jangaron.net/ofc5/data-files/joo.html#joo.debug> (for
example charts.Area) and "inline" all member functions declared in the
upper part into the "Jangaroo part" at the end of the file, you'd end up
with my FalconJx proposition. What you save is to give all method functions
a name, which could clash with other identifiers.
I guess that's how I am gonna re-create the as-js-runtime-prototype
JavaScript code: Compile the original AS3 sources with Jangaroo 3 and
inline the member functions and initializers.
If you need more / other examples of how the JS output of some AS input
should look like, I can thus create it for you in no time. You could even
do that yourself (if you prefer), by checking out the "jangaroo-3" branch
of jangaroo-tools <https://github.com/CoreMedia/jangaroo-tools/> and
building it via Maven. For the compiler integration tests, there are *.as
files that are automatically compiled.
If you have any more questions, I am here, listening!
Greetings,
-Frank-
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
