"static" vs "script local" (was globals)
Dar Scott
dsc at swcp.com
Sun Sep 8 15:55:01 EDT 2002
On Tuesday, August 27, 2002, at 10:21 AM, Richard Gaskin wrote:
>> 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.
>
> This latter type is sorta halfway between what VB and other
> languages call
> "static variables" and what the OOP world calls "private
> variables". It may
> have been less confusing if MC had adopted a new "static" keyword
> to reflect
> this very different type of declaration.
...
> Also, FWIW the revised Script Style Guide was updated to include
> reference
> to this new variable type:
> <http://www.fourthworld.com/embassy/articles/ScriptStyle.html#Naming>
>
I have a few minor concerns with the terminology of "static" for
"script local" variables in Revolution.
I don't think one new to Revolution might always have heard of
"static", "automatic", "dynamic", "scope", "extent" and the like in
the jargon of computer science. I don't think we all would agree
on the meanings. I probably misuse some.
Also, it tends to focus on one aspect of the variable, so it, too,
falls short as description.
When a new script writer looks at "script local" and "handler
local" variables, he or she can easily assume that the first is
visible to all commands and function applications in the script and
the latter is visible only to commands and function applications
within the handler. This is true as far as it goes--it is a
partial understanding, but it brings out the most important
characteristics--well, those I think are most important for a new
script writer.
Because "script local" variables are visible to multiple handlers,
for this to be meaningful and useful, the variable should have a
long life. Indeed, if we assume that objects are created and
script properties are set only at development, the life of the
variable is the time from open/start until close/destroyStack (or
similar--I'm probably missing some cases).
No doubt, it is this property that is implied by "static". Yet as
I mentioned, it is easily inferred.
What about the life of the "handler local" variables. Well, it is
possible to give these the same long life; many programming
languages do. Not so in Revolution--handlers will forget the
values of "handler local" variables as soon as they complete.
What happens when handlers and functions call handlers and functions?
If Revolution Transcript were a language like Logo, (with "dynamic"
scope), the initial intuition of a command using a variable
referring to one defined "script local" can be wrong. If
Revolution worked like this the "handler local" variable used is
that in the handler if any, or that in he calling handler if any,
on up to that "script local" variable. The name "static" for
"script local" provides no clue as to whether Transcript is like
this. A programming coming from Logo might be surprised.
What happens is that a new instance of the "handler local" variable
is (virtually) created each time the handler or function is
called. The word "static" for "script local" gives no clue for
reasons given above. (The term "temporary" in the above mentioned
web page, does a little.) In the execution of a handler commands
refer to the instance created for that call, that is, that
execution. New script writers run into this only whey they expect
handlers to remember or they write (sometimes accidently) recursive
routines.
I have not sat down with two sets of 100 students and tried one
with "static" and the other without. However, I don't think the
word will help much. Or if it does, some other naming scheme might
work even better.
I think that using terms so that those new to Revolution have it
easier, is a great goal, though.
(Transcript has the constraint that a "script local" variable and a
"handler local" variable within the same script cannot have the
same name--this adds to the constraints on variables.)
Dar Scott
More information about the use-livecode
mailing list