Comments on: Compile-Time Constants

By: c1

c1 — Sat, 31 Mar 2012 07:00:10 +0000

I thought that you would like to know that you can in fact define constants from within an Actionscript file.

config namespace MY_NAMESPACE;
MY_NAMESPACE const CONST_1 = true;
MY_NAMESPACE const CONST_2 = true;

See this link for more information :
http://wiki.ecmascript.org/doku.php?id=proposals:program_configuration

By: jackson

jackson — Thu, 22 Jul 2010 22:07:51 +0000

A deal breaker for using FDT or compile-time constants? Even with the annoyance of FDT_IGNORE, compile-time constants can have huge payoffs in very hot areas of the code that may outweigh the inconvenience.

By: Nick Bilyk

Nick Bilyk — Thu, 22 Jul 2010 21:14:46 +0000

FDT’s lack of conditional compilation argument support is a deal breaker for me. FDT_IGNORE tags are problematic for obvious reasons.

By: jackson

jackson — Wed, 18 Nov 2009 23:49:59 +0000

You're right, too. :) None of this would be necessary if the compiler just inlined constants for you. Instead, const is just a synonym for var other than some error checking to make sure you don't inadvertently change the value. Maybe in a future version of MXMLC they'll address this and we can get rid of workarounds like these.

By: Alec McEachran

Alec McEachran — Wed, 18 Nov 2009 23:19:41 +0000

You’re right, of course. Sorry for making my point so clumsily, and thanks for the tip John.

I suppose my main gripe is to do with the compiler; I hate to see code readability sacrificed for compilation issues. Compiler’s should be artful enough to sort this out without workarounds.

By: jackson

jackson — Wed, 18 Nov 2009 18:11:56 +0000

Speed definitely ain’t everything, which is why I bothered to point out the annoyance caused by having your constants outside of the AS3 source. However, I think you could mask this pretty well since the constants you define are actually AS3 code that is simply evaluated at compile time. For example, you can easily have a simple name-value pair file that is read in as an Ant properties file. Here’s an example math.properties:

pi=3.14159265
e=2.71828183
sqrt2=1.41421356

This should be understandable by any programmer (or non-programmer) but still, as you point out, it’s something “special” that a newbie would have to learn. I think that, for a one-minute lecture on where the constants are and why, the payoff is huge! Integrating it into an Ant build should be easy too:

 file="math.properties"/>
...
 executable="mxmlc">
     line="-define=MATH::pi,${pi}" />
     line="-define=MATH::e,${e}" />
     line="-define=MATH::sqrt2,${sqrt2}" />
    ...
>

To me it seems like, in the grand scheme of a project, a quibble. Of course everyone is free to decide for themselves just how big of a deal this is for their project.

By: John Lindquist

John Lindquist — Wed, 18 Nov 2009 12:41:48 +0000

@Alec – if you’re using FDT, wrap compiler constants with /*FDT_IGNORE*/ to make the errors disappear.

By: Alec McEachran

Alec McEachran — Wed, 18 Nov 2009 09:36:09 +0000

I thought this is where you were going, Jackson ;) Thanks for the thorough analysis, though.

I disagree with you though that a lack of #define is a quibble. A major concern of mine is that code should be as readable as possible. Although a constant name should be readable in itself, in this case the constant’s value is separated from the code into a command line argument. If the constant was the sort of thing that migth be tweaked from time to time (unlike PI!); how do I go about changing that? If I’m a coder new to the project, how do I find it? It adds a layer of complexity that I dislike.

Annoyingly too, if you’re using FDT (and probably other editors) you’ll litter your code with errors making discerning the real errors harder to discern and devaluing the tool.

It is good to know about, but I don’t like it because of these concerns. Speed ain’t everything!