[Laszlo-dev] compilation properties, options, and environment
ben at laszlosystems.com
Mon Jan 15 12:44:11 PST 2007
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"  and see where those emotion-words point to a coding
decision that can be improved in the light of changing requirements.
 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
> 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-
>> org.openlaszlo.sc.Compiler.options (compilerOptions)
>> 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
>> 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
>> ben at laszlosystems.com
Software Engineer, Open Laszlo / Laszlo Systems
ben at laszlosystems.com
More information about the Laszlo-dev