Le 22/02/2012 15:30, Martin Heidegger a écrit :
The point of the functions-files is that you don't create huge code
dependencies: Say you create a dependency to StringTools.endsWith() then
the compiler better compiles all functions of StringTools into the swf
so it can be loaded properly. In AS3: If i just create a dependency to
one function file (without a prefixing class) then it will just include
this one function, once. Allows a slimmer swf, doesn't it? Having import
statics will not solve that problem, right?
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.
Aside from that, I read a little into the Macro language and I wonder
that is really implementable, I think specially about things like:
var b: String = "foo";
var a: XML = <{b}></{b}>;
// <foo></foo>
or
var a: XML = <b/>;
a = a + <c/>;
// <b/><c/>
Can that be implemented with Macros?
The idea of macros is that you cannot modify haXe syntax, but you can
enrich semantics, so you could have the following :
var b : Srting = "foo";
var a : Xml = XML("<{b}></{b}>");
We have "real this" support in local functions : it means it's the
"this" of the class in which the local function is declared, not the
one of the "current this" in which context this function which be
called. This gives real strict typing since we don't know the latter.
The AS3 compiler creates automatic method closures. I am not entirely
sure how they are treated by the Flash Player. It seems I lack the
vocabulary to describe the difference properly so I attached a zip. The
haxe version will display "b" where the as3 version displays "a". I hope
with this I can make myself clear.
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.
This "logic" is very important through all AS3 code I have ever seen.
The "JavaScript" approach of handling "this" requires a lot of
rethinking within the AS3 community as many concepts won't work anymore
as expected - or just with hacks.
Agreed.
Not really an issue there, the documentation format is flexible and
you can get your raw /** ... **/ comments as XML output and deal with
it as you wish.
But it doesn't do it out of the box? I mean: translation? asdoc allowed
using additional xml files to inject translation based on property flags.
That depends on documentation tool, this is just a matter of XML
manipulation, no showstopper here either.
Binding essentially modifies the code to send events on change. So if
you write
[Bindable]
public var foo: String;
then it makes something like
public function get foo():String {
return _barMD5;
}
public function set foo(bar:String):void {
if( _barRandomKey != bar ) {
dispatchEvent( new PropertyChangeEvent("propertyChange", _barRandomKey,
_barRandomKey = bar) );
}
}
and if the class wasn't extending EventDispatcher before than it will be
"modifed" to do it now. Horrible mechanism..... but comfortable to use.
Thanks, definitely doable with macros, since it allows you to write
custom compile time code generators directly in haXe, without modifying
the compiler itself.
Best,
Nicolas
