Well,
I'm not a compiler expert, have a basic undertaking of AST, parsing and
compiling it back to desire language.
In fact I didn't even grasp a Java side of FalconJS yet. But knowing the
Adobe way of doing things I wouldn't be surprised if somebody have it
worked out a better way.
Adobe itself stated many times, it is a concept, prototype, experiment.
I lost my attitude a bit by watching their presentation yesterday, when
the main developer presented so many layers involved in the entire
process. Including jQuery as support for animation and interactivity.
But I took a look at this as it was a cannon fodder for developers to
calm them down during a difficult PR time for them.
But I know what the community is capable of, and seeing stuff like
jangaroo (I went trough Kevin's blog already, very good read) and many
initiatives I remember from the past, like make AS3 evaluators, AST
parsers etc. Flexibility of JS is vast, but the key to good performance
is one, stay native. Key for us is that we already have an good
structured environment. And Kevin, as the 1st comment on your blog under
http://blog.jangaroo.net/2011/11/simulating-actionscript-in-javascript.html.
We don't have to worry about violating fields of OOP so much, since we
are protected by language of the platform. But I see you guys have put a
lot of thinking and ideas in how to make the performance the best
possible. I am sure that ripping of the obstacles we can go even further.
Mike, if your assessment is correct and you see much bigger potential in
this. What can I say, the goal is the same, translate AS3 to JS. Does it
need to be falcon? This is what Adobe told/promised us, but...
Dan
On 11/29/2012 12:06 AM, Michael Schmalle wrote:
jangaroo/jooc/backend/JsCodeGenerator.java
This is the exact pattern I was talking about implementing. I think
it's so solid and you have done a great job at implementing it.
As I have said in previous posts today, The way FalconJS digests it's
AST is through SWF visitors. You are using straight AST from your parser.
Folks, having Frank drop this line and the discussions going on at the
moment, there are definitely a couple different paths that can be
taken with producing javascript.
If I have my way we would use an implementation like Franks, the
problem with it as it stands in Apache is there is no infrastructure
built like Frank has built, this is why the engineers used an SWF to
represent that infrastructure.
The problem with the current SWF/JBurg implementation is it VERY
confusing for most developers. With Franks implementation I was able
to understand what he was doing today within 20 minutes and could jump
right in and start coding things. With the current FalconJS emitters
there is no way that would happen.
So, I would love to see if we could think about a common goal to
energize both projects and see where one could help the other. I truly
believe now by looking at the code BEFORE this post our projects have
the exact same goal but can do different things.
Mike
Quoting Frank Wienberg <fr...@jangaroo.net>:
Hi folks,
here is another "outsider" who would like to contribute to the JS
runtime
format, if you are interested.
I am co-founder of the Open Source project Jangaroo, and as such have
been
dealing with JavaScript-to-ActionScript-3 compilation for several
years now.
In response to Bernd Paradies blogging about FalconJS, I blogged about
"simulating ActionScript 3 language features" extensively:
-
http://blog.jangaroo.net/2011/11/simulating-actionscript-in-javascript.html
-
http://blog.jangaroo.net/2011/12/simulating-actionscript-in-javascript.html
-
http://blog.jangaroo.net/2012/01/simulating-actionscript-parameter.html
-
http://blog.jangaroo.net/2012/01/simulating-actionscript-rest-parameter.html
All described solutions are actually implemented in the Jangaroo
Runtime,
which takes care of the code translated from AS3 to JS by the Jangaroo
Compiler coming alive.
In principle, we follow the "classic route", with the exception of
how we
simulate private members: see the first two blog posts.
At first look the Jangaroo Runtime may seem overly complex to you,
but it
does many more things (class loading / dependency management; class
initialization = execute static code at the right time; allow keeping
generated JS code and source AS3 code as similar as possible; automatic
method binding / correct "this", etc.), and the concepts described in
the
blob posts also work without these additional features.
The Jangaroo Compiler is written in Java and has a separate code
generator
(well you obviously won't need the parser) which might be worth having a
look at:
https://github.com/CoreMedia/jangaroo-tools/blob/master/jangaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/backend/JsCodeGenerator.java
If you dare to use Maven ;-), it is really easy to play around with our
code generation: Just set up your own projects within minutes, starting
from an example project like
https://github.com/fwienber/jooflash-app-template or
https://github.com/CoreMedia/jangaroo-ext-as-examples .
Greetings,
-Frank-
Frank Wienberg
Software Architect & Jangaroo Evangelist
*frank.wienb...@coremedia.com*
* frank@jangaroo <fr...@jangaroo.net>.net*
CoreMedia AG
content | context | conversion
Ludwig-Erhard-Str. 18
20459 Hamburg, Germany
www.coremedia.com
Executive Board: Gerrit Kolb (CEO), Dr. Klemens Kleiminger (CFO)
Supervisory Board: Prof. Dr. Florian Matthes (Chairman)
Trade Register: Amtsgericht Hamburg, HR B 76277
--------------------------------------------------------
