To global or not to global?

November 12, 1998
by Alex Zavatone

Variable storage & organization, an alternative approach

When we start out using Director and discover globals, often our titles end up with many more globals than necessary and after a year or so, we try the push to 1 or even less globals for "organizational purposes" and neatness. However, when you have many managers or objects that should be able to be accessed globally, storing everything in one global can be a real cumbersome operation when you want to actually get the values in those globals. Often for the sake of organization, you have to go through another layer to get to the data you want. More organized becomes cumbersome. So for a while, I would declare globals for the objects I needed. gSoundMgr, gScrollingFields, gNetworkOps, etc, etc.... But on a recent project, I once again came across the need to have what I call "scopeable globals."

A scopeable global is a global scoped to your current movie and can't be seen from outside it. This is particularly important when working in MIAWS where you don't want to stomp on the stage's or another miaw's globals. In previous projects, I would use the actorlist to store my objects. This is good because any stepframe handler in an object in the actorlist automatically gets called, providing a per frame service method for all objects within the actorlist. It was also good because there is one actorlist per stage movie and per miaw. The items in one would not stomp on items in another actorlist. But this is also bad because the actorlist itself can not be a property list and therefore, it is not easy to name your objects by a tag and reference them the same way. Fortunately, there are other places to store your variables that can be as private as lingo will let them be.

For instance, I created a parent script called "data container" and in it placed a property defination called pData. Just 1 line, that's it. In my movie startup script, I placed my main object into pData of the script (NOT an instantiation of that script) with the following line of data:

set the pData of script 1 = new(script "main obj")

And the contents of script 1 looked like this:

property pData

Now the actual script 1 itself becomes a data container and can be accessed at any time! Instead of declaring a global, I would set a local variable to reference pData like so:


on myHandler
set mainObj = the pData of script 1

To reference any of the properties within the main obj, you would use a line like this:


set the pMyProperty of mainObj = myValue
set myLocalVariable = the pMyProperty of MainObj

Thats it! We now have globals without using globals. If you want more containers, just add another property to script 1. You don't need ANY handlers in the script at all. Just define the properties and the script will hold the info you want to store. If you've got an object inspector, you can even enter script 1 into the object inspector and have it view all the contents realtime - a nice benefit.

In addition to this approach, you could even make an actorlist within script 1 - and make it a property list so that all the objects could be referenced by name.

This approach can also be extended for more flexability. It is a common approach to declare a global outside of your handler and at the top of your script but not within your handlers. This has the benefit of declaring that global for all the handlers within the current script member. I asked some of Macromedia's developers about this approach, and at times they said it's no problem and other times, was told it was a bad idea because it may not be supported in furute releases. Translation: use at your own risk. But if you're feeling risky, you can declare script 1 as a global, say gData, at the top of your script then gData becomes automatically becomes visible to all the handlers in your script. If you need more organization, you could even have several scripts that operate as containers and just a few globals to recognise them.

Now there is a small speed hit with this approach but even on a 6100 or p60, it's so small that it's not noticable. What it gives you in flexibility of data storage more than makes up for the miniscule speed difference.

Source explaining this is availble for download (Mac or PC).

A Director user since 1987, Alex (Zav) Zavatone has worked on the engineering teams for both Director and Shockwave, 4, 5, 6 and 7. Recent investigations find him developing foundation classes for Director with asynchronous process management and other life threatening activities. In its early days, he had something to do with this Internet thing known as "DOUG". A noted ne'erdowell, slacker and laggard, Mr. Zavatone is nonetheless is trusted by children, small animals and the elderly. In his spare time, Mr. Zavatone rehabilitates lame desert trout.