Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <20121130052730.14144dsl2lslbcpe@teotigraphix.com>
Date: Fri, 30 Nov 2012 05:27:30 -0500
From: Michael Schmalle <apache@teotigraphix.com>
To: flex-dev@incubator.apache.org
Subject: Re: [FlaconJS] pseudo emitter algorithm
References: <CCDCD9FE.4936F%aharui@adobe.com>
 <20121129124202.18057ehcvp03wmsq@teotigraphix.com>
 <CAD8jDGLrnwJq4i=75Fp3h=dJURCTpe+jxxRKxxtbj58aaebJZA@mail.gmail.com>
In-Reply-To: 
 <CAD8jDGLrnwJq4i=75Fp3h=dJURCTpe+jxxRKxxtbj58aaebJZA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=ISO-8859-1;
 DelSp="Yes";
 format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.3.11)

Quoting Frank Wienberg <frank@jangaroo.net>:

> On Thu, Nov 29, 2012 at 6:42 PM, Michael Schmalle
> <apache@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


-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com