What's wrong with Globals?

[Jim Ault]

On 3/30/07 3:18 PM, "Joe Lewis Wilkins" <pepetoo at Cox.Net> wrote:

> Please enlighten me. With HC I never really had any problem using
> Globals pretty extensively. I know all of the "old" adverse thoughts
> and how it was felt to be bad programming practice; and, perhaps,
> before we could have some pretty long vars, maybe it was tough coming
> up with names that didn't create conflicts, but I think we're past
> all of that now. So... why is using Custom Properties any better than
> using globals. I need to be convinces. I suspect a few of you have
> first hand experience and I'd like to hear them.

Nothing wrong with them, just some downsides for data management in larger
projects.  Declaring a global makes it exist, therefore you cannot easily
test to see if it has been used before the moment you declare it.  Testing
for empty does not mean that another handler did not create it.

Basically, globals are all owned by Rev, which means you can close a stack
and remove it from memory, but not the globals.  You need to delete the
global or quit and relaunch Rev.

Globals can be modified by any handler in any stack, even the Rev
environment (all that stuff behind the scenes).

Globals are not saved with the stack, custom properies can be, but this may
not be an issue in most cases.

My biggest benefit is that globals fill the variable watcher and make
debugging a lot more challenging.  When I name my globals, I prefix with "z"
so that they appear at the bottom of VW, and the script locals with "x" so
they appear just above the globals.  Just my little quirk.

You can use the same custom property name to store different information
such as 

---using a global ---
get the short date
put it into line (the number of this card) of gLastVisitToThisCard
--of course, now where to store this for next time

--using custom properties
get the short date
set the cpLastVisit of this card to it
save this stack
--now each card has its own data
set the cpLastVisit of this stack to it
--now the stack holds the last date any card was visited
set the cpCdIdVisited of this stack to the short id of this card
--now the id is stored

---In a substack
put the cpCdIdVisited of stack main stack into cdIdToUse

thus globals are general locations, custom properties are specific
locations.

Further, if you open a stack from somewhere to check out the tutorial,
example, etc,  those global declarations stay with Rev and overwrite any
previous values.

Part of the idea is that now your data has a specific place to be attached
that disappears with the stack or substack when removed from memory, yet is
still accessible, even if the stack is not open.

Script locals are a better management technique in my opinion.

Let us not even get into the power of custom property sets and storing
arrays in this thread.  Very powerful stuff.  A custom property set is the
same as an array... it has a name, keys, and elements.  You can have as many
as you like.

Jim Ault
Las Vegas