On 23/02/2012 00:48, Nicolas Cannasse wrote:
Well, speaking of the niceties of haXe, we have
--dead-code-elimination now that will only include in the output the
methods/fields actually used by the application.
That is treating the symptom not the problem. The dead-code-elimination
(like unused protected functions) is a problem if you load subsystems at
runtime that adress other parts of the same Structure. Things like
Reflections become unreliable - tiny inconsistencies. I find it very
good that I can define a hard reference just to the methods I need.
Splitting them up in is a lot like splitting classes up in files -
theoretically you put them all in one put but there are good reasons for
this separation.
The idea of macros is that you cannot modify haXe syntax, but you can
enrich semantics, so you could have the following :
var b : String = "foo";
var a : Xml = XML("<{b}></{b}>");
I see - very powerful system I must say - even thought the result is not
a comfortable to read. These particular two lines of code look a lot
like magic if someone from another programming language (say
ActionScript) saw it the first time. But I can see where you are coming
from.
Yes, haXe also automatically create method closures, the same AS3
does. It also do it automatically for JS target for instance.
The part I was refering is when using "this" in a local function, such
as :
class Loader {
function load() {
myMC.addEventListener(Event.COMPLETE,function(e) {
this.onComplete();
});
}
function onComplete() {
}
}
in haXe case, "this" is always the object in which the local function
function has been declared, not the one on which the event listener is
added.
Did you see my example code? I am not sure how to name that particular
difference.
In ActionScript you can pass a method reference like this
addEventListener(Event.COMPLETE, this.onComplete);
And any caller of this anonymous function would be calling the this
where its coming from.
That depends on documentation tool, this is just a matter of XML
manipulation, no showstopper here either.
I see - then this would mean a bit of work.
Thanks, definitely doable with macros, since it allows you to write
custom compile time code generators directly in haXe, without
modifying the compiler itself.
Cool. Sounds good.
yours
Martin.
