flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Arno" <da...@davidarno.org>
Subject RE: [gosh] Compiler choice [was Goshhawk language choices and more]
Date Mon, 20 Feb 2012 15:07:41 GMT
> From: niel.drummond@googlemail.com [mailto:niel.drummond@googlemail.com]
On Behalf Of Niel Drummond
> Sent: 20 February 2012 07:45
> 1) Wait for falcon, projected stable release late 2012, early 2013. 
This to my mind is the most risky of your three options. We wait a year,
then maybe get a compiler, which will be of unknown quality and usability.
Then we'd have to start work on getting it to support MXML properly.

> 2) Write a cross-compiler for flex from scratch.
This is, IMO at least, the best of your three options. It will be tough, but
if enough people get involved then I see no reason why we couldn't achieve

> 3) Port the SDK to haxe (or build a converter)
Tried that and gave it up as a bad idea. There are numerous problems with
this approach:
1. haXe doesn't support numerous aspects of AS3, such as custom namespaces,
E4X, global functions and internal and private namespaces.  Porting Flex to
haXe would be a non-trivial task.
2. haXe compiles everything from source files. It has no support for
partially compiled library files. Whilst it is fast for small numbers of
files, this really doesn't scale well for larger applications, such as those
using the Flex SDK. From the tests I did, I estimated that needing to
recompile the SDK source files every time one did an application build would
add 1 - 2 minutes to the build.
3. The SDK wouldn't just need porting to haXe, it would need rewriting to
add lots of conditional compilation directives to it to control how it built
to SWFs and to JavaScript.

haXe is a great little hacking language (though don't call it that or indeed
a toy language in front of Nicolas Cannasse, as he took offense when I -in
my subtle-as-a-brick fashion - referred to it as the latter,) with a great
community around it. It just isn't the sort of thing I like to offer up to
an enterprise-type customer who'd normally consider Flex solutions.

Of course it's worth wondering why no one except Michael Labriola is
considering the fourth option in all of this: stick with the existing mxmlc
and compc compilers. They may be slow, but they work and in theory we are
supposed to be getting the source for them straight away, not in a year's
time. Perhaps we should be putting more effort into investigating modifying
them to output JavaScript, Android and IoS native etc?


View raw message