> In {a.b.c} the compiler has to understand what a, b, and c resolve to,
what [Bindable] metadata there is on each one, etc. It uses the syntax tree
and the symbol table to do this.
This is very far from reality. What compiler does is actually like this:
< ... {the expression that appears in between the curly bracket} .../>
==>
var anotherBinding:Function = function():* { return the expression that
appears in between the curly bracket; }
It builds the trees and does all the code analysis much-much later after
all bindings are already generated into AS3 code. So, at the time of
binding generation the compiler has no idea what's inside the expression.
It only knows where it copied the expression from so that once the AS3
lexer or later layers of the compiler find an error, it will know to
reroute it to the place where the error happened in the original source
code (which, quite often doesn't work). In some special cases the compiler
can analyze the type (probably functions, classes, strings), but this is
rare.
I would also repeat that we are trying to solve the problem too early. We
really need to have a direction and a plan of what to do with MXML. So far
it is an ad hoc created set of random rules, it repeats all the mistakes of
the early programmers (from before 30 years ago at least). This initiative
is very good in the sense it welcomes this discussion and some more
analysis, but we really need to formulate the strategy and rules we want to
keep to when dealing with MXML. There are a lot of things good and bad we
have to at least compare MXML to before we start making changes.
Some things to consider:
cpp (C++ preprocessor and templates)
Lisp macros
T4 templates in MSVS
JSP / Coldfusion
MXML today is a concrete set of rigid arbitrary rules, in terms of the
development of computer science this roughly equals to the
early assembler macros predating C and C++, where this was already made
more generic and configurable.
I think we could do better than that.
Best.
Oleg
