mmerlin,
>I put the line "PRIVATE ALL LIKE g*" at the very beginning of the application so no matter what I don't have collisions elsewhere in the application
That alone won't make every g Variable private, meaning: Such a PRIVATE command is not defining all g variables private for the whole application scope.
PRIVATE is preventing private variables to "bleed into" your code, it hides variables which exist beforehand, it doesn't define variables. Since main is the start there are no previous variables, which could bleed in from outside, even not as command line parameters.
>Local variables are declared as "PRIVATE ALL LIKE <whatever>" at the beginning
That statement makes more sense, if you use "PRIVATE ALL LIKE <whatever>" at the beginning of every function, procedure, method, then all variables you create in your code, will be new variables and not change private variables coming from outside.
As you are such an old timer FoxPro developer I know you know better than how you explain it. If you "declare" local variable via PRIVATE ALL LIKE.., as you say, you never declare local variables, but only use private variables, as here:
Code:
test = "test"
? "before myfunc:"
List Memory like t*
myfunc()
? "after myfunc:"
List Memory like t*
Function myfunc
Private test
*Local test
test="test2"
? "inside myfunc:"
List Memory like t*
If you run this as is you see you have two variables test with scope "Priv"ate. The first one is associated with the whole prg, the second one with myfunc. And the first test variable is "(hid)"den. It unhides, after myfunc ends.
If you comment the Private line in myfunc and uncomment the Local line you'll see the local definition of the test variable also prevents usage of the private test variable, it also does not destroy the private variable, but it also doesn't hides it. Nebvertheless after the LOCAL declaration the name test refers to the local variable, not the private. If you uncomment both PRIVATE and LOCAL, you hide the private variable and introduce a local variable. Doesn't hurt.
If you never use LOCAL, you only declare private variables, if you always use PRIVATE in functions defining new private variables, you just end the private scope of variables already defined at that point and therefore your private variables become locally scoped, but LOCAL is there to create real local variables and private is there to introduce variables with a scope bound to the stack level. It's not scoped to a certain object or anything else, but only the call stack level.
The one advantage PRIVATE ALL LIKE l* additional to LOCAL declarations has, is that you could forget a LOCAL declaration and you still don't influence private variables.
I sometimes stated here or elsewhere, you could put PRIVATE ALL EXCEPT goApp at the begin of every function, procedure etc. That is even more radically refusing every variables bleeding in, except goApp, an application class instance to hold every globally needed data and functionality. But you have to understand every PRIVATE statement in code cares for all things in memory before that point in time and callstack, not afterwards. Beginning from then you can declare private variables with any name by just writing var=value somewhere and won't change such vars defined beforehand. the EXXCET clause can also be used to allow certain known and wanted private variables, eg in recursive functions. This can be overwhelming faster than passing variables by value.
So PRIVATE allows to define the namespace that you want to keep out and want to use to create new private variables starting their scope at the current stack level. But PRIVATE ALL EXCEPT goApp doesn't make every variable except goApp private. It just hides any private variable that may exist even accidentally and I can even forget to declare some variable LOCAL without the risc of overriding a private variable value. Nevertheless I use LOCAL all the time at the head of functions, procedures, and methods. Sometimes even with AS type, and often enough with comments to tell the meaning of the var. It's a good place for documentation and overview, instead of cluttering code with comments where variables are first set, for example.
Bye, Olaf.
