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
