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 :)
