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: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Date Tue, 24 Apr 2012 17:38:09 GMT
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

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