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.

View raw message