On Jan 15, 2007, at 4:54 AM, P T Withington wrote:
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
Really? Fascinating. Can you tell me more of this history?
c) The options are created in python and passed to java
Right, that's exactly where I'm getting confused, replacing that
python with java. It's done in a very dynamic-language way, but then
when we get into java we would like to be able to just check boolean
and (basically) enums explicitly. If we stayed in a dynamic language
the whole time, this structure would be less onerous.
It would be interesting to grep the code for "kludge" and "bleck" and
"argh" [1] and see where those emotion-words point to a coding
decision that can be improved in the light of changing requirements.
[1] See also http://osteele.com/archives/2005/12/aarg
It would be great to see a proposal on how to straighten this out.
I will think about it in the background. Seems like it will need a
standalone figure-out-some-of-java-1.5's-language-features little
project first.
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).
Ah. What compile-time constants must be 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.
Oh good -- a business case for cleaning this up. :)
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]
Benjamin Shine
Software Engineer, Open Laszlo / Laszlo Systems
[EMAIL PROTECTED]
