You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Martin Heidegger <mh...@leichtgewicht.at> on 2012/02/23 04:50:59 UTC
[RT] haxe reality check
Hello List,
Thinking about it a little I think its good to clear up the mind about
haXe. So I want to summarize the things about it
haXe...
* ... contains a very fast and good avm2 bytecode compiler (that does
things Falcon will do in future - today).
* ... has established and tested a way to create JavaScript code from
a AS3-like language.
* ... is also a language and it has a bunch of language features that
would help AS3 dearly.
* ... has a system called Macros that would allow us to implement e4x
like structures or bindings on top of existing code.
Now, I see two ways Apache Flex could leverage haXe:
1) Port Apache Flex from AS3 to haXe.
haXe compiles to swcs. If Flex were to be ported to haXe and
creates the swcs with the same content then
AS3 projects could continue to leverage those swcs but also
switch to haXe as a programming language. There
are some things important to know for this:
- haXe does not have any e4x support yet and there are no
plans to add it to the language. Any support would need
to be done using Macros.
- haXe does not offer standalone functions/variables so it
will not be possible to entirely replicate the current API
- haXe does not offer namespaces, we would need to drop those
code or become incompatible on swc level.
2) Branch the haXe compiler and add AS3 syntax.
Create a new compiler based on haXe without breaking
ActionScript 3 and implement features such as e4x,
regexp (is currently done using strings), namespaces and other
operators. And it would need to implement
MXML - lots of work. There is just one thing that bugs me, aside
from the ton of work:
- the haXe compiler is GPL - that means its category-X [1] -
the resulting compiler could not be hosted on Apache
With both approaches there would still be open to:
- Implement compilation of various embedded assets such as
Fonts/SWFs/etc.
- Create sophisticated documentation templates - rudimentary in haXe
I hope I didn't forget anything crucial.
My personal conclusion is that haXe is a nice system. It achieved a lot
of things but: without major efforts in haXe as
a system (compiler/tools) its not possible to migrate Flex. A change in
language comes with new
concepts and ideas and Flex would logically be built differently for
haXe. Porting flex to haXe seems less
reasonable than writing a new system for haXe to me and I wouldn't name
that Flex. Using the compiler for an alternative
compiler for AS3 sure seems fun and if it ever bears fruits I will be
glad to use them.
yours
Martin.
[1] http://www.apache.org/legal/3party.html#category-x
Re: [RT] haxe reality check
Posted by ganaraj p r <ga...@gmail.com>.
The very purpose behind going towards a Haxe implementation of Flex is to
make it platform agnostic ( VM agnostic? )..
If we can do this with the least amount of pain, then yes.. Haxe can be a
very possible and viable choice. Ofcourse going to another language means
losing some of the features that are there in the native one. This is
something we have to accept I guess. Suppose we go to JS, do we have E4X
there?
If we can write the flex framework on top of Haxe, there is going to be a
myriad languages we can support. The same framework sitting on top of
multiple platforms. That is what...attracts me..
On Thu, Feb 23, 2012 at 8:53 AM, Left Right <ol...@gmail.com> wrote:
> There is a confusion about the way in which E4X will not be accessible - it
> is only inaccessible to you, as a form of syntax, when you write code in
> HaXe. You can use methods of XML class (it's also referred to as E4X
> sometimes). So, if you wanted to do:
> xml..*.@foo
>
> you couldn't write that in HaXe, but
>
> xml.descendats().attribute("foo");
>
> would work. Only things impossible to translate are the filter operator and
> namespace access operator.
>
> But this only means that whoever writes the framework code will be limited
> to these features only, but whoever uses compiled framework with Adobe
> compilers still can use E4X however they want to.
>
> Re' standalone functions - it is possible to use them, it's just
> uncomfortable to use them in HaXe. You would do something
> untyped
> __global__["flash.utils.getDefinitionByName"]("flash.display.Sprite");
>
> probably, you would do something like:
>
> inline function getDefinition(name) { return untyped
> __global__["flash.utils.getDefinitionByName"](name); }
>
> so that it looks nicer.
> bu I don't think the converse will work, i.e. __global__["multiply"] =
> function(x) { x * x; } probably won't do anything, or not what you'd hope
> it may do. Ha, now I'm curious :)
>
> However, GPL vs Apache license seems like a tough one...
>
--
Regards,
Ganaraj P R
Re: [RT] haxe reality check
Posted by Niel Drummond <ni...@grumpytoad.org>.
Just wanted to drop a small note.
If it is decided to prototype something in haxe, or check whether a
required feature can be implemented with macros, I'm happy to provide
help coding, advise or fetching the right person from the haxe
community.
All the best,
- Niel
On 23/02/2012, Martin Heidegger <mh...@leichtgewicht.at> wrote:
> On 23/02/2012 17:53, Left Right wrote:
>> There is a confusion about the way in which E4X will not be accessible -
>
> e4x is a language feature. Different access is per-definition not e4x.
> It just means we would
> need to use other tools.
>
>> inline function getDefinition(name) { return untyped
>> __global__["flash.utils.getDefinitionByName"](name); }
>
> Yes, it would be possible to use the functions but it would not be
> possible to provide
> functions or constants that Flex users could refer to.
>
>> However, GPL vs Apache license seems like a tough one...
>
> As long as the things in haXe are not required to be checked in it would
> be good enough.
>
> yours
> Martin.
>
--
Sent from my mobile device
Re: [RT] haxe reality check
Posted by Left Right <ol...@gmail.com>.
That was mostly intended to answer what Michael Labriola said in another
thread (it kind of gets spread across multiple threads, or Gmail can't keep
the track properly, if people reply with different title message).
What he said was something along these lines: "there are large projects
that use Flex and they employ XML-based communication". And so my answer
was that they could continue using that / it would hardly make any
difference to them, so far the runtime provides the API for the code
they've written. The only limitation is for programmers maintaining the
framework code, which is, to be honest, not really a limitation - it is,
arguably, longer syntax to use all the same API. (there is no runtime
function to backup filter operator, for instance, it translates into a
loop, but with a weird popping and pulling the context in and out of the
stack when the code inside the filter is executed. So, in practice, it was
never a good idea to use E4X filter in the first place... (it's by
definition worse then a regular for-each loop).
There is an idiomatic way for HaXe to provide global functions - it's done
through <language package>.Lib class. Indeed, there's no common way to
provide functions on per-package level. Well, that's a disadvantage, but,
in my opinion, it's only a matter of coding practice - in Java you cannot
do that too, and nobody cares :)
Re: [RT] haxe reality check
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 23/02/2012 17:53, Left Right wrote:
> There is a confusion about the way in which E4X will not be accessible -
e4x is a language feature. Different access is per-definition not e4x.
It just means we would
need to use other tools.
> inline function getDefinition(name) { return untyped
> __global__["flash.utils.getDefinitionByName"](name); }
Yes, it would be possible to use the functions but it would not be
possible to provide
functions or constants that Flex users could refer to.
> However, GPL vs Apache license seems like a tough one...
As long as the things in haXe are not required to be checked in it would
be good enough.
yours
Martin.
Re: [RT] haxe reality check
Posted by Left Right <ol...@gmail.com>.
There is a confusion about the way in which E4X will not be accessible - it
is only inaccessible to you, as a form of syntax, when you write code in
HaXe. You can use methods of XML class (it's also referred to as E4X
sometimes). So, if you wanted to do:
xml..*.@foo
you couldn't write that in HaXe, but
xml.descendats().attribute("foo");
would work. Only things impossible to translate are the filter operator and
namespace access operator.
But this only means that whoever writes the framework code will be limited
to these features only, but whoever uses compiled framework with Adobe
compilers still can use E4X however they want to.
Re' standalone functions - it is possible to use them, it's just
uncomfortable to use them in HaXe. You would do something
untyped
__global__["flash.utils.getDefinitionByName"]("flash.display.Sprite");
probably, you would do something like:
inline function getDefinition(name) { return untyped
__global__["flash.utils.getDefinitionByName"](name); }
so that it looks nicer.
bu I don't think the converse will work, i.e. __global__["multiply"] =
function(x) { x * x; } probably won't do anything, or not what you'd hope
it may do. Ha, now I'm curious :)
However, GPL vs Apache license seems like a tough one...