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