"static" vs "script local" (was globals)

[Dar Scott]

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