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 <olegsivo...@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
