rcozens at pon.net
Tue Aug 27 10:33:01 CDT 2002
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.
CCW, Serendipity Software Company
"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)
More information about the use-livecode