incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ganaraj p r <>
Subject Re: [RT] haxe reality check
Date Thu, 23 Feb 2012 09:35:20 GMT
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

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

Ganaraj P R

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message