incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Cannasse <ncanna...@motion-twin.com>
Subject Re: Flex adopting haXe ?
Date Wed, 22 Feb 2012 12:02:27 GMT
Le 22/02/2012 12:35, Martin Heidegger a écrit :
> However I used ActionScript a lot in the past years and found ways to
> work with it that are unlike the work with haXe because when I recently
> tried out haXe again I was bothered by a few language features that I
> use heavily in ActionScript and have not found a good equivalent in haXe
> (in other words: they are missing in haXe - aren't they?):

Well, I think most of them comes down to design choices. Instead of 
focusing on what AS3 have and haXe does not, maybe focusing on what haXe 
has and AS3 haven't would also be useful ? Unless it's a clear 
showstopper feature of course.

> *) Standalone variables/constants/function files outside of a class
> context. I found them very liberating and as far as I can tell: haXe
> only allows class/ENum/ alike.

We have plans for Java-like "import statics" for haXe 3.0 : this will 
enable you to import all statics of a given class into the global namespace.

> *) e4x: Its such a pleasure to use in AS3.

We have haxe.xml.Fast API which is maybe not as much powerful as E4X but 
still very convenient for quick XML parsing. It should be possible to 
write a quite complete E4X equivalent with haXe macros.

Keep in mind also that XML is being replaced in lot of cases by JSON.

> *) Default initialized properties:
> class ABC {
> public var x: int = 1;
> }

Is this really a showstopper feature ? :)

> *) Working "this" in function references: Using function references has
> become such a normal thing in AS3 that I wouldn't know how to implement
> a similar design with without them.

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.

> *) Namespaces: While I don't "like" namespaces particularly, porting
> Flex to haXe might be difficult without it.

Indeed. But Javascript does not have namespaces either, so if you want 
to compile to JS you'll have to deal with it somehow.

We have a pending draft for access control customization. It's not yet 
implemented but could be done in matter of days, please check it there :
http://haxe.org/manual/acl

> *) Compiling the "asdoc" to different locales

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.

> *) Documentation on Meta-tags

Like http://haxe.org/manual/metadata ?

> *) Binding

I'm not familiar with Binding, but it needs to either be translated to 
property access or another corresponding low level feature. I guess this 
can be achieved with compiletime code generation thanks to macros, and 
again using such not-native scheme will enable it to work on all 
platforms supported by haXe as well.

> *) Assets (Fonts!) loaded compiled through meta-data

We have support for bitmaps so far, by using :

@:bitmap("myfile.png") class Bmp extends flash.display.BitmapData {
}

Other assets could be easily added as well, there's already third party 
tools for that.

Best,
Nicolas

Mime
View raw message