incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Left Right <olegsivo...@gmail.com>
Subject Re: [RT] haxe reality check
Date Thu, 23 Feb 2012 08:53:10 GMT
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...

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