globals

[Rob Cozens]

Mark, et al:

>>That would mean every time one wrote a handler one would have to
>>check EVERY local variable name to make sure it was not on the global
>>list.  This would include handlers in other people's stacks as well
>>as your own.
>>
>
>Doesn't Rev already do something like this for the built-in 
>constants and properties and what-not on compiling?  I have tried to 
>use variable names before which caused the script to fail as the 
>name was already 'taken' by something.

Reserved words are a different animal.  For one thing, they are all 
documented and universally known to all Rev developers.  For another, 
the list cannot be added to by other developers..  If you want your 
stacks & apps to run seamlessly with other Rev stacks & apps, how 
would you know what globals were declared in the other peoples' 
stacks, or what non-declared local handler variables in others' 
stacks had the same name as your globals?

>
>>
>>I was able to replace all globals in my original HyperCard library
>>design with locally-declared variables.
>
>Isn't removing the distinction between global and local variables 
>(by eliminating one entirely) a little like picking all the raisins 
>out of your raisin bran?  You do all this extra work to end up with 
>boring bran flakes.  Well, to each his own.  Whatever works for you.

First, lets make sure we are using the same terms.  There is a 
difference between "locally-declared" variables and "local" 
variables.  HyperTalk allows:
1. global variables, whose values persist until the engine quits and 
are accessible to any handler in the runtime environment.
2. local variables, whose values persist only so long as the handler 
runs and are accessible only to that handler.

The MetaCard engine recognizes a third type, locally-declared 
variables, whose values persist until the stack closes and are 
accessible to any handler in the script.

You asked for the functionality of global variables without having to 
declare the global in every script (you wrote "handler", but I 
presume you now know you can make the declaration in the script 
outside of any handlers and have it apply to all that reference the 
variable).  I was trying to show you how that can be done by 
extending the accessibility of locally-declared variables.

To use your analogy, global raisins in my bran are available to any 
handler in the current runtime environment that wants them.  They can 
also be had accidentally, when the a calling handler asks for 
raisins, not knowing that another handler has been messing in the 
bran already.  Locally-declared raisins are only available to those 
handlers within the scope I dictate.  So long as the get & set 
commands have different names in different scripts, duplicate local 
variable names can never cause a name conflict.  IMFO, it is global 
variable users that risk ending up with boring bran: any handler in 
any stack/app can get to one's raisins; whereas if a locally-declared 
variable user winds up with bran, it's because he/she has already 
eaten all the raisins.
-- 

Rob Cozens
CCW, Serendipity Software Company
http://www.oenolog.com/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)