incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Left Right <>
Subject Re: [RT] haxe reality check
Date Thu, 23 Feb 2012 13:05:14 GMT
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 :)

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