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. > _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
