incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [FlaconJS] pseudo emitter algorithm
Date Mon, 03 Dec 2012 05:45:57 GMT



On 12/2/12 2:21 AM, "Frank Wienberg" <frank@jangaroo.net> wrote:

>> 
> There is one important aspect to consider when deciding which route to take.
> If you, like Bernd Paradies, see JavaScript's role in this process as an
> machine language, it is completely valid to generate JS code from ABC.
Well, I would like the release builds to run as fast as possible, but
debuggability is more important, IMO.
> But this is not the viewpoint we take for Jangaroo. We chose ActionScript,
> not Dart, TypeScript or Haxe, as the high-level language to compile to
> JavaScript, because it is so very similar to JavaScript. In fact, it is a
> super set of JavaScript, so that you can copy-paste JavaScript code into
> your ActionScript program and it works!
> When you look at Jangaroo-generated JavaScript code, it closely resembles
> the original ActionScript source code. We optimized the compiler as well as
> the runtime to give the impression that the JS code is actually the AS code
> that you, the developer, wrote. Every source file results in a separate JS
> file, which is also loaded separately in "debug mode".
I'm ok with that as long as it loads reasonably quickly.

> Even the line
> numbers are kept precisely. This allows for debugging directly in the
> browser without the need for any additional / new debugger tools.
> Of course, this approach would not be possible at all when generating JS
> code from ABC, not from AS/AST.
> 
> We would like to provide something similar for MXML, too. So the ideal
> solution would be a mixture of the approaches described in this thread.
> Combine Alex' datastructures and the AST->JS approach. This is also very
> similar to how Ext JS UIs are specified using nested JS Object literals.
If you look at the prototype, it does not use nested object literals.  I was
unable to get them to perform as well as the data stream I am using or the
methods it is replacing.
> The idea would be to generate AS code from MXML that contains both the
> datastructures and the code fragments (<fx:Script>), keeping the line
> numbers (if possible).
It is probably possible to maintain line numbers for script blocks, but what
are the advantages of maintaining line numbers in MXML?
-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui


Mime
View raw message