flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Left Right <olegsivo...@gmail.com>
Subject Re: Flex adopting haXe ?
Date Wed, 22 Feb 2012 13:07:15 GMT
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 :)

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:
So, for example something like:


would look like:


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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message