>
> > 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; }
>
Right. I am pretty sure that changes to a['b'].c will not get executed in
this case, even though it should be resolved the same as a.b.c
Om
On Tue, Apr 24, 2012 at 4:57 PM, Left Right <olegsivo...@gmail.com> wrote:
> > 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
>
