Re: Adobe / Apache / Spoon Flex Tour

[Left Right]

Roland:
At the time I did some poking around MXML parser and code generation, I
can't claim myself to be an expert on the issue, but I know some. So,
here's my view of the situation: you say it works in Intellij, I say it's
pretty much broken. Here's why: possibly, you only used the features you
encountered in manuals Adobe put online, and you used them the way Adobe
wrote them. I, on the contrary, was looking to reduce the code generation
bloat, and was looking to do it the way the compiler can still handle, but,
it might look less common. For example, you would do:

<mx:Script><![CDATA[ private function clickHandler():void { trace("hi!"); }
<mx:Button click="clickHandler()"/>

I would do:

<mx:Button><mx:click>trace("hi");</mx:click></mx:Button>

There are many other examples, I don't want to bloat this thread.

Particular plaque in Intellij is debugging MXML - the debugger is not smart
enough to understand what generated AS file is derived from what MXML, so
no breakpoints for you in MXML files most of the time.

Intellij AS3 parser only understands about 90% of AS3, thus, for example {
(true.valueOf()) : false } would be highlighted as an error, yet it's a
valid AS3. It's MXML parser was based on some hardcoded tables, thus, the
projects I worked on were usually painted in all red (the color to
highlight a syntax error :)).

Re' MXML - it ultimately cannot handle constants - stupid design, sorry. It
generates bindings for constants as if they were variables. The major fault
in the design is that the authors decided to remove quotes from around
string values in attributes. I'll explain.

If it was <foo stringProperty="'stringValue'"/>, then you could've made
constant expression simply by copying whatever's in between the first and
the last quote, but if you do <foo stringProperty="stringValue"/> - there's
no way to tell, whether stringValue is a reference to some definition by
the name stringValue or is it a literal string spelled "stringValue". This
design flow resulted in tons of ad hoc code in MXMLC to resolve this
ambiguity. It actually never cared to be systematic, thus, for example, in
certain cases function references may not need binding braces, but in other
situations they do and so on. It's pretty random and unsystematic.
There are other rules enforced by MXML, that lack any kind of common sense
- it must use some namespace from a variety defined in... bah, compiler
source code! how's that? :) You cannot access a property of a read-only
property - why? - no reason, just so you'd ask. You cannot pass arguments
to constructor - for the very same particular reason. You cannot define
access modifier, again, why - you know that already, right? I could
continue, but I'll keep some for the future :P

* * *

Languages: I thought I argued my case, but I'll try to explain again, the
plugins and the "mothership" compiler need not to run inside the same
runtime - there is a traditional way to make programs cooperate - pipes,
stream, well, you know. This is called modular architecture, or, if you
like that Unix-like approach. Even if Java is widely used, this doesn't
mean it's widely liked. WinAPI are a chore, but you cannot avoid it,
because, in the end of the day, most software in the world runs on top of
this crap. What I'm saying is that, for once, you are given a chance to do
things properly! :) Learning new languages? - pew! if it's a good language,
then why not? Besides, I think I said that people who would get seriously
involved with the compiler aren't your average $10/hour freelancers, they
might actually know some stuff about language design, and, almost
certainly, Java won't be the language of choice for them :) Besides, those
languages are cool, no, seriously, if you indeed like programming, you
enjoy writing and perfecting the code written in them, unlike this kind
of... masterpiece http://govnokod.ru/8865 (the piece of the code in the
quote remained like that since before Adobe took over Macromedia, it's the
remains of the rewrite of Macromedia old compiler, probably written in C++).
But not only they are cool - they are in many respects a better tool for
the job, they can do certain things pertaining to specific to compiler
tasks way better then Java will ever possibly do. One more important thing
- there are academic works and researches standing behind them, which are
the bread and the air for someone who lives and breathes language design,
compilers, computation etc. If you hope to invent, to advance, this would
be the way to go.

* * *

Re' ANTLR - well, as I said, it's a tool for generating parsers for certain
types of grammars, namely LR(1), or, to rephrase it, for LR(k) grammars,
which can be made into LR(1) - this implies AS3 must be an LR(k) grammar.
This, in other words, means that AS3 must be a deterministic, context-free
language, yet it seems to me that it is not. For example, depending on the
context square brackets may be interpreted as metadata or array (there are
places, where compiler actually makes an arbitrary decision as of today),
semicolon... I hate to say that, but it would be so much easier, if it was
mandatory... it was soooooo stupid to make it optional... anyways.
So, what I'm saying is - it is highly possible that ANTLR, or any other LR
parser generator simply won't do the job because such job cannot be done by
this kind of programs. There may not be an alternative, but to handcode the
parser, or give up on certain language features to fit it into LR(1)
grammar.

* * *

One more thing I forgot to mention before, with regard to MXMLC, the whole
block dedicated to backing up the framework code, all the junk files like
FlexInit, SystemManager, _global and so on - this should be clearly kept
away from the compiler. It's insane it was made this way to begin with :)
At the time, I was thinking of a separate module to compiler, responsible
for AS3 source generation based on plain text templates. What I actually
ended up doing - using PHP as source code generator, however, having a
compiler module that could not only generate source by string replace, but,
actually analyze the code would be certainly better. Still, I'd rather it
be based on plain text templates then hardcoded into compiler itself. This
holds true for resource bundles generation, all kinds of -services configs
etc.

Mansour Blanco, you actually don't need XSLT, MXML is built on top of
Velocity, a monstrous beast that can do all kinds of tricks, handling loops
being not even a particularly remarkable one of them ;)

Best.

wvxvw