Alex,
I have no idea what I am talking about. :)
I have not dealt with enterprise things at all. I'm just a programmer
in the woods so to speak.
I am just trying to clarify things before I head out on an arduous
path of creating some js from AST.
I do agree that there has to be savings by not creating a SWF then
using it to create JS, when in theory you had that AST to begin with
at the start of the compiler's parsing. It seems like the savings
would be at least 1/2. I do think there will need to be analyzers or
some type of middle ground (delegation/analyze) between the parse
stage and generation stage.
My only question was, were the engineers doing anything specific with
resolutions and such with the SWF.
The fact that jangaroo does it with AST is good enough for me to get
going on a prototype. I was just trying to see if there was anything
where I am not reinventing the wheel. But I will, if that is the only
way to go since the API is externally different then jangaroo.
Using the IDefinition API, with loaded SWCs gives you member and class
resolotuion so I might actually start with that higher level and not
strictly IASNode parser nodes.
Mike
Quoting Alex Harui <aha...@adobe.com>:
You guys have lost me a bit.
IMO, all I want as output is a series of .JS files (that would later get
minified by GCC for release builds). I don't get how the JSEmitter's
reliance on SWF output constructs like traits would affect the output.
Seems like you should be able to generate the same thing from the AST.
Potentially even faster than having to unravel the MethodInfo/MethodBodyInfo
constructs.
I also don't see how the fact that Falcon consumes SWCs in order to resolve
the symbols at compilation time affects the output either. And isn't SWC
consumption all you really need for modular development? You shouldn't need
the module binaries, the two projects should be sharing a common interface.
In my mind, modules are separate .js files loaded at different times. The
key is if you can minify them without destroying their common interface.
Someone said you can tune GCC to do that.
Anyway, good point about closed source since all JS is open. But all
enterprises moving to JS just be dealing with this some way already right?
Isn't minification about as good as abc code in the SWF? You could always
dump a SWF and get most of the algorithm back.
Or maybe I'm totally missing what you guys are talking about.
-Alex
On 11/30/12 2:27 AM, "Michael Schmalle" <apa...@teotigraphix.com> wrote:
Quoting Frank Wienberg <fr...@jangaroo.net>:
On Thu, Nov 29, 2012 at 6:42 PM, Michael Schmalle
<apa...@teotigraphix.com>wrote:
For FalconJS this process is totally bound to SWF format.
This was my point. For any developer to fix bugs here they have to know
the SWF format. Which I don't.
This is why I propsed another solution using pure AST like Jangaroo does.
I am not skilled enough to understand the trade offs currently. But I am
going to try and see if I can create the same JS code using a different
algorithm.
I guess the trade off is that the AST approach leads to a different
packaging format. For Jangaroo, we use JARs that contain the generated JS
code as well as generated AS "API stubs" (under META-INF/joo-api), that is
the AS code is reduced to its API, using the "native" keyword. This allows
to compile against other modules without having their source code. However,
the consequence is that you need a different classpath and custom build
tools: we created a Maven plugin that provides a custom packaging type
currently called "jangaroo" that outputs a JAR in the format described
above.
When the output format is SWC/SWF, you more closely resemble Flash/Flex.
But honestly, unless we transform ActionScript byte code into JavaScript
(or interpret it in JavaScript like in Gordon's approach), we cannot use
any "binary" modules, anyway, but instead all modules have to be recompiled
for use with FalconJS, or even worse you need the complete source code for
the whole project, which would increase build time and hinder real modular
development as well as closed source modules--quite a show stopper for an
Enterprise tool!
-Frank-
Ok, I didn't even think about the recompile. So in my mind, please
correct me if I'm wrong, the SWC/SWF probably was chosen because it IS
the packaging and organization structure currently. Where you are
using a jar as you said. Correct?
Since you have so much experience with as->js, what is your opinion on
implementation? I'm asking because I might be putting a lot of work
into the compiler output and would like to know which direction. Do
you see any way of interfacing jangaroo and falcon/falconjs?
Do you think offering the straight AST emitter(which would allow
granular compiles with native stubs) like yours AND the SWF/SWC option
and somehow getting them on the same API is something to consider?
As I said earlier, you have some great code, I would love to work
together somehow to get a nice application framework our there like
Flex ontop of JS and whatever other language we could get to, Android,
iOS, whatever.
Thanks for all your time Frank!
Mike
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
