incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Cannasse <>
Subject Re: Flex adopting haXe ?
Date Wed, 22 Feb 2012 15:48:51 GMT
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) {
   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 

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


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


View raw message