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
