>Hiya Mark,
>
>I've got really mixed feelings about this one. I understand, however, that this is what you want. I'm not terribly sure, though, that it's a very good idea. Let me explain.
>
>For anyone new to what compile time constants are and why we use them, let's first go over that. By creating them you reduce memory consumption, increase performance and, make your programs easier to read, and thus, maintain. The most important thing to remember here is that this is supposed to be a constant.
>
>While on the one hand it does make it easier to read CURRENT_DEFAULT_PATH, than SYS(5) + SYS(2003), it is exactly what it says, because it is re-evaluated whenever it's referenced. It's more like a system variable rather than compile time constant. That bothers me, and perhaps it should bother you too. Consider...
>
>What if MS decides that this behavior, strictly because it's inconsistent with the intended, is a bug and fix it later? Whoops! All of a sudden you've got a very difficult to track down bug. All those references to CURRENT_DEFAULT_PATH, are actually references to COMPILE_TIME_DEFAULT_PATH.
>
>Anyway, that's my take.

I agree. I have flip-flopped on this more times than I care to count. The DEFAULT_PATH was just one example. I have used a variable for system function values then changed them to constants and back. To follow the strict definition of a constant and OOP design, I should resort to an app object property [which I do in that case]. There are other examples where I am going to be quite resistant to removing them from my constants file because of pure convenience.

I also read into the MS warning of not to use them in the eExpression as a of a future bug fix possibility.