On Mar 13, 2012, at 1:17 PM, James Cowan wrote: > > MXML/AS3/Flex are conceptually identical to XAML/C#/WPF. They borrow a lot of > ideas from previous XML UI technologies. > MXML/haXe/Flex does sound quite viable.
Sure, it could be done. But i guess someone should be willing to port the actionscript code. A mapping on haxe-nme should be possible as it implements the flash displaylist. some challenges here: ================== - the code base is huge - bindings. Could be solved with macro's i hope - embed and other metadata. Could be solved with macro's i guess - actionscript has 4 access modifiers, haxe only public and private - namespaces are not present in Haxe, not sure how to solve that - E4X, but i'm not sure how much this is used in the SDK. - uint data type although i 99.9% of the cases it can be mapped on a Haxe Int (i just ported a SHA256 from actionscript to haxe that used uints and it works) - AND Probably MANY issues that i forgot to mentio here... But, if you want to do that it's probably best to extend the as3hx project (see haxe trunk) which does basic translation from as3 to haxe and try to solve those issues described above in an automated way. IF you could solve all those isuess in an automated way then you could every time the flex trunk changes generate an automated haxe port :-) so if you got that all working, which would take a while then you could at least test performance etc. If that's ok then the fun part. Write a MXML (or Haxe Markup Language :-) compiler front end for haxe... It would be a massive amount of work and i didn't mention the hard things like modules, resource bundles, runtime libs, swc's etc. But indeed it would be very nice! cheers, arnoud > > The issue is that both Silverlight and Flash are dieing and haXe represents a > future for Flex because it is clever cross compiler > technology that targets lots of platforms - native o/s including mobile via > nme/cpp, vm via neko, browser via js and swf and in time java/c#. > > The problem with haXe is that a language/compiler is only a part of a > development environment - libraries/frameworks for persistence and GUI > are as important. If I could develop in haXe and use a haXe enabled Flex as > my GUI framework and a haXe enabled ORM (on the lines of > JPA/Hibernate) as my persistence framework and then could target > desktop/javascript/swf/mobile from the same code base, that would be awesome I like haxe's own SPOD implementation > It may be a pipe dream if every library has to be rewritten at the source > level and I can understand anyone baulking at that. I will ask Nicolas > if there might be a way of interfacing Flex or say Hibernate (when the java > target is ready) without rewrite at source level. I imagine he will > point at the migration tools and say that once the migration from AS3 to haXe > is done, one would dump the AS3 code. > > I live in the town where "Flash on the Beach" had its last year - there was a > big local Flash community but now it has moved on to Javascript (with canvas) > and to mobile and they are much more interested in > HaXe/Corona/Titanium/Marmalade than Flex/Air mobile. > > Java/Swing failed on the desktop and the browser (applets) mainly because of > runtime issues (and competition from Microsoft/Apple) and I would be sorry to > see Flex die because the runtime (Flash) died under it. > > I would certainly see a future for Flex on Flash/Air technology if Adobe > donated the defunct Air for Linux to Apache and Apple issued a statement > embracing it > on OSX but I do not see this happening soon. Air and flash runs on osx / IOS, so why bother? > > James
