incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Heidegger>
Subject Re: Flex adopting haXe ?
Date Wed, 22 Feb 2012 14:30:27 GMT
On 22/02/2012 21:02, Nicolas Cannasse wrote:
> 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.

 From the AS3 developers (my) point of view the list of things that haXe 
is not capable of is more important as it will interrupt our current 
concepts. That is why I focused on it. I think its important to know 
about it in this list.

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

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?

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

Specially due to the lack of proper documentation and validation of JSON 
(namespace...) - xml will stay a standard that is used in enterprise 
environments still for a while. Specially with namespaces e4x is a 
blessing. However: This just means that we would need to help with e4x 
macros for haXe.

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>


   var a: XML = <b/>;
   a = a + <c/>;
// <b/><c/>

Can that be implemented with Macros?

> Is this really a showstopper feature ? :)

Initializers are not a show-stopper but incredibly handsome on the daily 
job :)

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

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.

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

Theoretically namespaces are hackable using prefixes. Even though they 
would consume quite some javascript size I guess.

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

That is a very nice draft. Looks awesome!

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

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.

>> *) Documentation on Meta-tags
> Like ?

I am talking about a way to document the meta data (like [Style]) use. 
that can be represented in the asdocs. In UIComponent for example all 
documentation of Styles [1]  can be found inline in the code [2] and is 
automatically created.

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

Binding essentially modifies the code to send events on change. So if 
you write

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.

> We have support for bitmaps so far, by using :
> @:bitmap("myfile.png") class Bmp extends flash.display.BitmapData {}

That is a big feature that was essential to many parts of the code. 
Embed fonts are very important. I have read of hxswfml but I am not sure 
how far that would go.



(see [Style...] )

View raw message