. Re: cross-stack globals, also, file inclusion

[Martin Baxter]

I'm no expert so correct me if I'm wrong, but as I understand it, constants
are a structurally different kind of thing from variables, and there is a
bit more to it than scripting style preference.

The major difference I don't think anybody has mentioned is that since the
value of a constant is known at compile time, it can be inserted directly
into the resulting object code. So the value has only to be looked up once
- at compile time - whereas a variable always has to be re-evaluated at
runtime. A variable that's got from an accessor would seem to be even more
work because a handler has to be run to determine which variable to look up.

Using variables where constants are properly called-for seems to me rather
like putting a function with fixed parameters inside a repeat loop - it's
just feels needlessly wasteful basically.

So I agree with Rob entirely, I would see global constants as a worthwhile
addition, and while mimicing them with variables is obviously workable
right now, I don't think it's really equivalent, or as good a solution.

Rob's file inclusion idea (if I understand it right) of in effect supplying
the arguments to a global constant declaration from an included file, would
seem like a potentially useful and elegant capability too. Exactly how it
would be implemented I don't know, and no doubt I'd just embarrass myself
(as usual:-) if I speculated.....

martin

>"J. Landman Gay" wrote
>
>On 10/24/03 9:52 AM, Rob Cozens wrote:
>
>> I have no doubt this is workable; but I see nothing here to convince me
>> that a cat skinned your way is necessarily better or worse than a cat
>> skinned my way.
>
>Nope. My only point is that there is already a reasonable way to
>implement global constants, and it keeps the language nice and compact.
>As I said before, I have no particular objection to adding global
>constants, I just don't see any reason to.
>
>> Remember, I mentioned "translatable" as well as multi-lingual.
>> Serendipity Library will load message lines in any language from any
>> text file with the correct number of lines.  Serendipity Library keeps
>> only the currently-selected language's text in RAM, and users can edit
>> the message text files directly to customize/translate messages, labels,
>> menuItems, toolTips, etc.
>
>You could as easily load a text file into a global array as you can a
>property set. No difference there, and as you say, it would cut down on
>memory usage. You could probably even use the same text files you are
>using now.
>
>> Give me a better reason to change my approach, and I'll look more deeply
>> into this.
>
>I'm not sure there's a "better" reason -- there is only a "right now"
>reason. What you want to do is available now, is easily implemented, and
>as far as I can see, requires only that you change the parentheses in
>your function calls to square brackets. You can probably even load the
>array from the existing text files on disk, and then need only refer to
>the elements using array notation instead of function notation. Seems to
>me that's the only change you'd need to make to implement global
>constants. Of course, I could be off base; I'm only going on what we've
>talked about here.
>
>So again, I see no particular reason to push for global constants. If
>people really want them, fine, I just don't think they are necessary
>because it is so easy to implement them using the existing syntax.
>