Thanks Nicolas, I was the one who mentioned you in a post and wanted your inputs on "How we could go about porting Flex to Haxe?".. I assumed that since you built Haxe ( duh! ) and that since Haxe is inspired by AS3, you would be able to provide some deep insights into the migration of Flex to Haxe.. If we even go ahead with it. These are a few questions that come to my mind..
1 ) I know Haxe is a budding and growing community. Has anyone attempted to get Flex onto Haxe? In terms of porting! Have you ever considered doing it ( Since it seems like a logical step to get more traction into the language itself! ) , starting it ? 2 ) Can you see any pitfalls of porting this huge mammoth (from the top of your head! )? 3 ) If we are going to go down the cross compilation route we have primarily 2 choices. Dart or Haxe. Why should we choose Haxe over Dart? Can you give us any insights and points to choose Haxe over dart? One of them , I can already guess is that Haxe is closer to AS3 than Dart is... Any other advantages? 4 ) Its usually the UI which is going to be platform dependent. The logic for most of the stuff can easily ported from one Platform to another. Does Haxe make you UI agnostic? What I mean is if we are going from Flash to Web then we need to map Sprites to something! So how easy would it be to switch from one to another.. Does Haxe do what JQuery and other frameworks do to Browsers and their implementation of javascript ? I might be wrong but I believe that the Flex community is much larger than the community supporting Haxe. So, I personally believe that porting Flex onto Haxe should turn out to be a hugely beneficial move in terms of Haxe, strategically. Anyways thanks for this mail. Its always great to get inputs from people like you when we are talking about open source efforts. On Wed, Feb 22, 2012 at 1:07 PM, Left Right <olegsivo...@gmail.com> wrote: > I think I could add more info on HaXe vs linking assets. > > There used to be a project SamHaXe - no longer developed, sadly. About a > year or so ago I made this plugin for FD to have some kind of graphical > interface for embedding different stuff it supported: > http://www.flasher.ru/forum/blog.php?b=187 (sorry, the text is in Russian, > but you could understand from the images what does it do, well, I hope so > :). > The way it used to work was different, but, in my opinion, better approach > then [Embed] meta - it used a resource file descriptor, which then would be > processed by the encoder (which was basically an adapter to other encoders, > such as Imagemagic for example), then you would "feed" the produced SWF to > the compiler as a reference. > > However, there is yet another project that does it, and it does it > significantly better: http://code.google.com/p/hxswfml/ this is something > that allows not only embedding, but also generating SWF graphical content, > such as shape primitives, text snapshots and so on. > > Other bonus points: it wasn't possible with Flex encoders to embed, for > example FLV video data or PCM sound data - I'm sure that HXSWFMill can do > the first, and almost sure about the last :) I'm not sure about what font > formats are supported though. > > Something about Flex binding: in a trivial case, it would be really a > trivial compiler macro, however, with some more complex cases, like, > binding tag used on class declaration it may not be so trivial (but, why, > why on Earth would you do that?..) anyways, that would be still doable, but > would involve more sophisticated macro. There are, however, more complex > things, which I, to be honest, don't even know how they function - the > [Inspectable] meta and whatever relates to live preview and stuff like > that. > > Re' ASDoc - sorry, but that wasn't a very good tool :( I mean, OK, it did > the job, but the HTML output from it is terrific. Try to feed the > documentation page to HTML validator service - it has hundreds if not > thousands of errors. But not only that, the generated HTML is not > optimized, it repeats a lot of things that needs not be repeated (it could > be actually reduced up to 50% as it is now, but given some thought it could > be even more). > On the other hand, HaXe is easily recognizable by tools like NaturalDocs, > which actually produces better quality HTML output. It requires different > type of writing the comments (it's not entirely different, but still). So, > if you think about documenting HaXe source, then it would hardly be an > issue. NaturalDocs is an established well-known tool used since like > prehistoric era, but still been actively developed and maintained :) > http://www.naturaldocs.org/ > > Re' E4X - many-many years ago I tried to "fix" this for myself :) It might > be a bit funny code, and it uses old XML API, but the concept should be > still understandable: > > http://code.google.com/p/e4xu/source/browse/trunk/haxe/src/org/wvxvws/xml/W.hx > So, for example something like: > > xml.*.(foo(valueOf()))..*.@bar > > would look like: > > W.alk(xml).c(foo).d().a("bar") > > It's not as fast as the original E4X, but it's not that slow really, and, > after all, if you wanted speed, you should be using XMLNode anyway. > > At the same time I started writing a validating SAX parser for XML, never > finished it though, but "finishing" it means ensuring things really work as > advertised. If implemented using fast memory, it could be, possibly, quite > fast, but even if not, then it would be still faster then a regular > expression based version. > > http://code.google.com/p/e4xu/source/browse/trunk/haxe/src/org/wvxvws/xml/Sax.hx > -- Regards, Ganaraj P R
