On Tue, Feb 21, 2012 at 11:15 AM, David Arno <da...@davidarno.org> wrote:
> > From: Left Right [mailto:olegsivo...@gmail.com] > > Sent: 20 February 2012 16:00 > > > > Well, HaXe can use pre-compiled code, since maybe more then a year > > ago I guess... It doesn't use SWC, but ans SWF as an input is OK. > > Probably Niel can elaborate on that, or correct me if I'm wrong. > Yeah sorry I wasn't very clear on that. The problem with viewing SWFs as a > usable input sourceflash9 xml calls is that they are only of use when > targeting SWFs. haXe > doesn't have any target-agnostic library support. > Haxe's community does develop target agnostic swf parsing libraries (see https://github.com/jgranick/swf ), though I would question whether swf is a good packaging mechanism for assets produced from flex in general, or assets that are more widely used in projects a year or two down the road (e.g. video / audio). It may be wiser to investigate using tarballs or other serialization mechanisms. > > I never found any practical use case that justified the use of internal > or > > > custom namespaces ... I see the absence of E4X as a good thing ... > Whether you, I or the framework use such features isn't the main issue > though as far as I can see. Unless we are imagining we would port the > framework to haXe, but then tell SDK users to carry on using AS3 and the > mxmlc compiler, we have to allow for the fact that both features are used > in > the wider community. Therefore I think that until a way to seamlessly > handle > those features in haXe is devised, it will be a difficult sell to the wider > community. > I don't think you will be able to write a cross-compiler without making some compromises, and e4X will be one of them. Jangaroo and the haxe community's attempts at this are evidence enough. It's not completely unlikely that e4x will eventually be implemented in js on non-gecko browsers, but it's a larger project in its own right, and I doubt it will satisfy anyone's performance hopes. See for example: http://groups.google.com/group/jangaroo-users/browse_thread/thread/953acd9f5965d149 Javascript has native XPath handlers, so getting any kind of reasonable performance will need to use those. For flex, the best option performance wise (I think) is writing a wrapper library that transforms calls into native XPath for JS or native e4x calls on flash. You could use the haxe xml library, but this is a regex based engine, and chokes at larger XML documents. I would imagine that custom namespaces could be implemented at a haxe macro level, because you can analyse the AST and it's annotations using haxe code before the compiler generates code. The next major haxe release is imminent, so I think if you are willing to place your bets on haxe, and you do need some compiler changes that are reasonable and target agnostic, then I think something could be done about it. Citing lots of javascript-incompatible features as a reason not to use haxe, is in my mind, not helping the flex community. - Niel > > Why not use MXMLC? - obviously, Adobe aren't going to support it, > > unless for maybe critical fixes, so if you are going to support it, > > you are quite on your own with that. > We will be on our own regardless of which compiler we choose, surely? The > mxmlc compiler is far from perfect, but it exists and works already. My gut > feeling is that you are right and that we should strive for something new > rather than trying to improve it. I just worry we might have been too hasty > in completely disregarding it. > > David. > >
