incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Left Right <olegsivo...@gmail.com>
Subject Re: Adobe / Apache / Spoon Flex Tour
Date Mon, 20 Feb 2012 12:30:31 GMT
Alex, then I have several more questions regarding the framework and
compiler integration. Previously, no one cared to separate these two
things, which resulted in that certain features of MXML weren't available
to non-framework code. For instance, UIDUtils would make dependency to
IUIComponent and through it to the rest of the framework. The code
concerning UIDUtils would be added by the compiler alone, with no regard to
the availability of this class and it's dependencies, and was impossible to
prevent.

Another such thing - the compilation of FXG - how Falcon will relate to
that? I am convinced that basing FXG on a Spark container made the feature
useless, or reduced it's usefulness to a degree it wasn't worth the effort.

Yet another thing - regardless of availability and _actual use_ the former
code generator would put a lot of imports into generated files - this
required you to have dummy files and, sometimes, entire folders to only
make the compiler happy.

Another thing, FlexInit - it has a "hand unrolled" loop (i.e. it repeated
same code over an over again) - regardless of me reporting the issue,
nobody cared to fix it, telling it's not a bug... how much better, if at
all the code generation is going to be? Will there be any way to affect it
from outside? Something that would be portable? (would not require you to
build the compiler from sources).

Generated code for resource bundles was redundant, for example, it would go
like this:

package ... { class bundle@name { function getBundle():Object { return {
"key" : "value" }; } } }

instead of doing it at least like this:

package ... { var bundle@name = { "key" : "value" }; }

To tell you the truth, there was a lot of such or similar code - I would go
on and assume that whoever wrote that had minimal understanding of how AS3
works, and probably came from Java background... the worse thing about it
was that it was not possible to alter this behavior in a portable way, that
is in a way that would not require you to recompile the compiler.

I am seriously worried about the new compiler when you say that things like
MXML are going to be built-in. Having long history of Adobe providing low
quality AS3 code, I would not like any code generation to be built into
compiler, or, at least, not in the way it cannot be _entirely_ altered.
I provided the example with locales because that was something quite recent
that I simply gave up on Flex compiler doing it right and did that myself.
I was lucky I only needed strings, no images or sounds. But if I had to do
that for other kinds of assets too, that would add a lot of work, and that
just wouldn't justify my rewrite, and I'd had to use whatever there is in
Flex, regardless of it's quality.

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