cross-stack globals, also, file inclusion

[Rob Cozens]

Thanks for your detailed response, Jacque.

I think this still boils down to "which way do you want to skin the 
cat?", as I see plusses & minuses for each.

>* My primary constant list is, in effect, an index to lines of text 
>in a file and/or variable

snip

>This is pretty much what custom properties are good at. You could do 
>all this in a single line of script. Say you store the message list 
>along with their ID numbers as a bunch of custom properties in a 
>button called "propBtn". Somewhere when the stack opens:
>
>   global sdbMessage
>   put the customProperties of btn "propBtn" into sdbMessage
>
>The global now contains an array. The keys are the message names, 
>and the values of each key are the ID numbers. In your scripts, you 
>use:
>
>   answer sdbMessage[badInputWarning]

In my design (Serendipity Library):

   local sdbMessages
   constant constant1 = 1
   snip
   constant constant263 = 263
   put field "Message Text" into sdbMessages

The line is retrieved using a function:

	answer sdbMessage(lineNumberConstant)

Whether it is more efficient to set 263 custom properties or type 263 
constant declarations is, to me, debatable.  (Include functionality 
would still be nice here.)

But underneath it all, perhaps I just have an intellectual aversion 
to the use of stack properties to store what are essentially compiler 
symbol names & values.

>
>>* My secondary constant list is used to facilitate handler modification:
>snip
>Same thing here again, only with a custom property array you really 
>do only need to change the value once, directly within the custom 
>property.

You've got me there; though for the sake of argument I would note 
that using properties for constants means the value of a "constant" 
can be changed by any runtime handler.

>>
>>* An ancillary use of constants is to support multi-lingual, 
>>translatable applications:
>snip
>One of the primary reasons for adding support for custom property 
>sets a couple of years ago was to support multi-lingual apps. This 
>is exactly what you need here. You'd create several custom property 
>sets, one for each supported language. You only need to do this 
>once, during development. When it is time to load the values, you 
>just choose the property set first before loading the array:
>
>   global sdbMessage
>   set the customPropertySet of btn "propBtn" to "Spanish"
>   put the customProperties of btn "propBtn" into sdbMessage
>
>Bingo, all your scripts work without modification, but the strings 
>that sdbMessage returns are in Spanish.
>

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.

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.

Give me a better reason to change my approach, and I'll look more 
deeply into this.
-- 

Rob Cozens
CCW, Serendipity Software Company
http://www.oenolog.net/who.htm

"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."

from "The Triple Foole" by John Donne (1572-1631)