I think I can explain the undefined order. The attributes are stored in the hash-map-like structure, which is unordered, so you cannot build on some attributes' values being assigned before the others. In languages which allow you to control how bindings are executed (for example, in Lisp or Miranda) you have special forms for bindings that allow referencing other bindings and others that don't. Forms that ensure that all bindings wait until values are created are more complex to implement, usually you try to avoid them in your program. For example, in Common Lisp these are: (let () ...) and (let* () ...) (flet () ...) and (labels () ...)
to illustrate it further: (let ((a 21) (b (* a 2))) (princ b)) ; error variable 'a' is unbound (let* ((a 21) (b (* a 2))) (princ b)); 42 MXML takes away the ability to define the order in which bindings are initialized (because using XML for source code templates is inherently a bad idea). So, MXML tries to act like the (let* ...) binding, but this is often redundant. The problem with implementing a simple (let ...) binding is that MXML is very primitive and it cannot infer that the binding creates circular- or cross-references. There is another problem - it is very common in AS to introduce side effects in setters, so even if you didn't create circular or cross-references, the side effects may bite you in the back, especially so when you don't know in what order they are executed. Yet another problem with this approach is that the generated code is undetermined. That is, if you will try to generate hashes from your compiled application, the person compiling your application will not get the same result as you did. Or will not always get it. You may not be sure that the version sent to QA is the same as you have in your development environment. Well, in other words - this is kind of a brainfart of an MXML inventor... it would be great if it was possible to solve it with a simple patch like this, but the problem is more generic than that. We actually need to change the MXML behavior in the way it is deterministic, or, at least, is deterministic on demand, even if this means longer compilation times. Best. Oleg
