This is definitely a fragile area of the system that could be made
better. It is in the state that it is because:
a) It evolved over time to meet different needs
b) The script and tag compiler were written as separate projects but
need to share some info
c) The options are created in python and passed to java
It would be great to see a proposal on how to straighten this out.
Note that compile-time constants are extra special because they are
used by the compiler to evaluate if statements at compile-time (its
how our conditional compilation works) _and_ they get inserted into
the output executable (for cases that could not be evaluated at
compile time). Sometimes a compiler option exists solely for the
convenience of setting several compile-time constants at once (e.g.,
--debug for LZX programs), while those constants may also be set
individually (e.g., the debug LFC has only some of the constants that
--debug would imply set).
One of the messier aspects of the compile-time constants is the way
we add a new runtime. There are too many places in the system that
need to be touched to add a new runtime. Just cleaning up this would
be a major accomplishment.
On 2007-01-14, at 23:47 EST, Benjamin Shine wrote:
The script compiler has two different collections-of-configuration-
data:
org.openlaszlo.sc.Compiler.options (compilerOptions)
and
constants (org.openlaszlo.sc.Compiler.COMPILE_TIME_CONSTANTS).
The map containing the constants is pushed into a single slot in
the options data structure, then pulled out when needed, and cast
to be a Map again. That is goofy.
A same-same-but-different data structure is
CompilationEnvironment.properties, but that has to do with the tag
compiler, not the script compiler. Confusingly, these all represent
some of the same information and some different information:
whether to debug/profile and which runtime are specified in all
three of these data structures. This looks confusing to me, and
fragile.
I can refactor this cleanly using java 1.5-dependent language
features -- collections, autoboxing, the for/in loop, type-safe enums.
Tucker, Jim, what do you think?
a) Not now
b) Let's see a more detailed proposal first
c) a & b
Benjamin Shine
Software Engineer, Open Laszlo / Laszlo Systems
[EMAIL PROTECTED]
