Global Variable Persistance & Scope

[G Gabriel]

Re: Global Variable Persistance & Scope

the question: if you even agree with this fellows ranting, would you say using dot globals is any more efficient for memory than just listing them individually?

Yes I do, but that fellow must be a PhD in a college with computers from the 80's!

First: I would use the narrowest possible scope of variables.
As to the second question, although I can't tell you for a fact, but at least in theory having your variables as dot variables would probably consume less memory. It's just the equivalent of having one table with 100 fields as opposed to 100 tables with one field each. But again, we are talking about such minute differences that in today's RAM of several gigabytes is only of theoretical significance, plus there is so much grouping you could do. The true difference is not in memory usages but rather in the fact that with dot variables you could do assignments in bulk, if it is something that you need in your code.
You can create dot variables as a name space (top variable, which should be p) and then the dot variables, or you could use with...end with.

[martinwcole]

Re: Global Variable Persistance & Scope

Excellent answers - thanks ever so much.

I just looked to see if global_variables() was available in v5, and it is. I have a global in a hospital app named area. And if I go to the control panel, and default browse and use alpha's built-in tools for finding records I get an error - it took me forever to figure out it was the global 'area' that was causing the problem. So when I go to the control panel I auto delete the global. With a dot I could eliminate the issue.

And the more I think about it, the better I like the idea of dot globals - for future apps. Speaking of memory, a lot of us still remember the early days when memory was a significant issue, and even after IBM came in with 512K a lot of the languages could not immediately use it and had to be rewritten.

Not sure why, but this reminds me of another tip I got from Selwyn about 3 or 4 years ago. And since I'm feeling a bit nostalgic this evening, I'll share it with you. An app I was writing for a LAN client wanted to use RTF Memo fields. I recoiled and shuddered a bit in a fear somewhat like the inate fear of snakes and such - considering their reputation. Well, Selwyn suggested saving a copy of the memo, if I was worried and if space was not an issue (now I remember why the remind!) Such a simple idea! Why didn't I think of that. Well I am pleased to tell you that after about 3.5 years on an active 11 user shadow, I have never had an issue with RTF Memos. My routine may have scared them.

The routine I came up with is that I first took all the normal steps (recommended by Dr. Wayne) with any memo - the memos are stored in their own table and when a new parent is made I also make a memo, so they are only ever edited. But I added another safety step. When the memo is created and/or edited, I save a copy of that individual memo in its own either table or text file in a subfloder (you can use either.) The idea is that if the parent memo table becomes corrupted and baloons, it will typically or maybe always be a single record that causes all the problems. And I made a restore routine for each memo table, since they have several, that will zap the parent and recreate it from the backup files. A consideration here, of course, is that if you have 10,000 records in a parent table you will have 10,000 individual backup files or text files. They currently have a little over 3000 after 3.5 years. But it has never been an issue.

Also, in defense of memos when handled properly, I vaguely recall Dr. Wayne saying he had over a million records in one table and had never had an issue. That was several years ago.

[csda1]

Re: Global Variable Persistance & Scope

Hi Martin,

a few years ago at a conference someone was giving a speech and was particularly critical of using global variables. Since I use global variables a lot (a big app of mine may have 100 or more global vaiables,) I was troubled by his comments. But since I have never run out of memory or had any issues, I continued/continue to use global variables.

the question: if you even agree with this fellows ranting, would you say using dot globals is any more efficient for memory than just listing them individually?

I don't know if it was myself or Cal, or someone else, who said it, but many would agree that the less number of global variables, the better.

But Global variables, or for that matter, and scope of variable does not matter whether it is accessed via a pointer or not. It pretty much amounts to the same thing. A global variable named xyz can also be accessed as such;

dim global xyz as c
xyz="123"
?xyz
= "123"
?global_variables().xyz
= "123"
gv=global_variables()
?gv.xyz
= "123"
altptr=global_variables()
?altptr.xyz
= "123"

It uses the identical memory for storage no matter how it's location is resolved. The only thing that is different is that items dimension global, shared or local go into specific pointer spaces, as opposed to explicitly referencing a pointer. If an item is referenced and not dimensioned, it searches for the name in 1st local, then shared, then global variables to resolve the name. This can cause collisions of names that are used in operations like query.filter. That's why dimensioning is so important.

The reasons for not using global variables include some of the following;

1. Alpha's built-in functions, use or generate a lot of global names, some very common, like

body
pointer_name
xx
xxx
query_name

These will cause problems with your code if you use the same names and happen to call functions using them. I had 1 client who ran into this by a global name of his own. If instead, you create a very unique global pointer like

dim global MartinsGobalValues as P

and then create and reference all of them via the pointer (or by using with/end with), you will never have an issue with name collisions.

2. When more than 1 session accesses the same variables and were not intended to, e.g. a variable named temp, you'll run into the same problem, and in fact, each session can be messing with the other session's variables. That is the reason for Shared or Local variables

Read my tips page on this that covers a lot more on this subject

[SNusa]

Re: Global Variable Persistance & Scope

Am I correct in my usage of pointers to eliminate problems as follows:

dim global xyz as c
dim global gPointer as p = global_variables()
gPointer.xyz="Text"

Then in the IW this will work:
?gPointer.xyz

If so, it all makes sense.

[csda1]

Re: Global Variable Persistance & Scope

Am I correct in my usage of pointers to eliminate problems as follows:

dim global xyz as c
dim global gPointer as p = global_variables()
gPointer.xyz="Text"

Then in the IW this will work:
?gPointer.xyz

If so, it all makes sense.

Not exactly, but close. You have placed a global pointer in the global space pointing back to itself. This tends to mess up enumeration and similar methods of global variables causing them to hang. They enumerate the global variables, then enumerate recursively those pointers which happen to have gPointer which points to global variables ad infinitum.


dim global xyz as c
' This assigns global variable xyz as "Text"
xyz="Text"

' This dimensions gPointer variable in the local variable space to point to the global space
dim gPointer as p = global_variables()

' This gets the pointer's space property (in other words variable) xyz
?gPointer.xyz

If xyz was never dimensioned, then Alpha 5 searches the local, then shared, then global spaces (and maybe addin space too - I'm not sure) looking for the 1st one that matches and returns that value.

[SNusa]

Re: Global Variable Persistance & Scope

So I gather the only correction to my code example is to simply drop the global assignment in the pointer's dim statment?

(I had noticed in your example, gv=global_variables() was implicitly declared, but that appears to be the only difference.
I was trying to apply your suggestions relative to "avoiding collisions" while accessing global variables.)

[csda1]

Re: Global Variable Persistance & Scope

Hi Robert,

So I gather the only correction to my code example is to simply drop the global assignment in the pointer's dim statment?

Yes, basically to not create "an infinite type loop"

(I had noticed in your example, gv=global_variables() was implicitly declared, but that appears to be the only difference.

If it doesn't exist, the implicitly declared variable is assigned to the local variable space, unless overridden with a WITH/END WITH with a different space. Had the variable already existed at a "higher" space, it would have found that and assigned it there. This one fact is the reason I changed my all my function code from implicitly dimensioned to explicitly dimensioned local variables back several years ago. It was finding variables outside the function, and this made it possible for external code to affect the function's operation (something that should never happen for most functions unless intended that way - functions should strive to be a "pure function").