Avoiding Global Variables - revUp 93

[Jim Ault]

My experience with people who are new to a language or new to  
programming tend to simplify or "round off" their efforts and produce  
the following:

Use globals as a short cut to passing parameters because it is simpler

Develop programming patterns that mean they use the same global names

Forget that globals are owned by Rev, not the stack(s)

Lose track of how many script containers touch and change the same  
global

Try to reuse globals, thinking that they will just keep track of  
clearing the global variable when they need to.


I used to be leader of the Advance Hypercard Special Interest Group  
back in the day.  The global naming was particularly problematic when  
a school teacher decided to jump in and do their own grade book and  
used:

global mySelectedStudent
-- as one declaration, without the 'g' prefix

-- then in field scripts, etc used
put "Tom Jones" into mySelectedStudent
-- forgetting to declare the global at the top of the script container
-- or forgetting they had declared it and it already had a value

-- or forgetting that the global value was supposed to be
         line 5 of field "studentList"
-- and defined it as the string "Tommy Smith"
--     thus dueling data formats

This became worse when they tried to employ "stacks in use", which  
meant that many globals became hidden library instances.  Now the  
globals were not even in the same stack or logical project.  They had  
a fighting chance if they were the authors of the 'stacks in use', but  
not when they acquired the stacks of others.

Our Hypercard group actually designed some scripts to map the globals  
and look for duplicate locals or missing global declarations.  Script  
locals were not a feature of Hypercard.  If the 'g' prefix were not  
used, mapping was essential for finding 'cross-wiring' (as we called  
it).

Hypercard was designed to run across hard drives and computers, so now  
globals became more difficult.  You had a choice to navigate and use  
the remote environment or keep using your own.  Remember the days of  
"Go Recent", "Pop Card" ?  On an AppleTalk network, like a classroom,  
this could lead to significant degrees of anarchy.  The students would  
use the same global names as the instructor, but for different tasks.

I found that most new programmers, including me, had challenges with  
the scope of variables.  Certainly experienced programmers have  
mastered the use of global variables and developed work patterns to  
use them wisely, thus they have become a valuable tool.  To the new  
programmer, they create extra bugs that are more difficult to find and  
fix.

There was one programming student who could not understand that  
globals were persistent, even if he closed his stack.  He would leave  
Hypercard running all the time, no matter which stacks he was  
developing or exploring.  Opening someone else's stack created  
variables you did not know about.

You can imagine at the end of 4 weeks how many globals were safely  
nestled into his application memory.  It was a clan of somewhat- 
related variables, most were of his own creation.  After all, part of  
the thrill of Hypercard was seeing all the wonderful stacks built by  
others.

Our Hypercard group rule was if your stacks were for distribution,  
sharing, and fun, don't use globals (or use unique names).

Hope this adds to the discussion by looking back to the beginning of  
the Hypercard-space-time continuum and the universal nature of globals  
and their nebulae.


Jim Ault
Las Vegas