Hi Nicolas,
Speaking from a purely enterprise point of view, in what way is haXe going
to help me in terms of scale, support, dev tools. Pardon me because I
haven't done my homework on haXe. Also, how is this different from
rhomobile?
Thanks
Avinash Y
On Wed, Feb 22, 2012 at 5:32 PM, Nicolas Cannasse <ncanna...@motion-twin.com
> wrote:
> 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 <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
>
