Global variables and dimensioning of same

[Steve T]

My reference is the book, Xbasic for Everybody - Page 149 (pdf). An example from this book, Global variables are created (dim) and assigned (=). The author continues to dimension (dim) the Global variables in other parts of the program prior to using the Global variable. Is there some rationale for this, I don't see the point. I realise the dim'ing of an already dim'ed variable doesn't destroy the assigned value but it seems superfluous to do so.

Any thoughts?

As an aside, I apply a naming convention to variables (coming from VBA) so at a glance I know a variable is global etc.

[Tom Cone Jr]

Re: Global variables and dimensioning of same

DIM'ing the variable in later scripts tells those scripts that you are referencing the global. Otherwise, the later scripts will implicitly DIM the variable as LOCAL. Alpha Five permits duplicate variable names, with different variable scopes. You can have both a global var and a local var with the same name. The rule I follow is simple: if the var is not DIM'd in the current script it's LOCAL.

[csda1]

Re: Global variables and dimensioning of same

Hi Tom,

Otherwise, the later scripts will implicitly DIM the variable as LOCAL. Alpha Five permits duplicate variable names, with different variable scopes. You can have both a global var and a local var with the same name. The rule I follow is simple: if the var is not DIM'd in the current script it's LOCAL.

To more precisely state it, if it is not DIM'd, and you don't reference an explicit variable space (addin, global, shared and local), the current most limited space that is DIM'd is used for references and assignments. If not DIM'd at any level, then there is implicit DIM as a local variable (or at the space as defined by the WITH/END WITH command directive)

Hi Steve,

For more info on Dimensioning see my Dimensioning tips, which cover's many aspects of variable use.

[Steve T]

Re: Global variables and dimensioning of same

Thanks for the replies.

To me it just looks a little strange when seeing a dim statement but no assignment statement immediately following, or within a few lines of code. Though I can live with it.

I've scoured the help file and can not find any reference to the possibility of globally issuing an 'Option Strict' command. Is it possible to issue such a command, once?

In any event in relation to global variables (no matter which language) common sense should prevail regarding what names are used. You'd be asking for trouble if names such as temp, name, x, y, z etc. were used.

[csda1]

Re: Global variables and dimensioning of same

Hi Steve,

To me it just looks a little strange when seeing a dim statement but no assignment statement immediately following, or within a few lines of code. Though I can live with it.

This is not a compiled (in the "C" sense") language. It is an interpreted, XBAsic language that has no idea what other modules are doing or have declared, until it does it. A DIM basically tells Alpha Five the scope (variable space) and type for that code piece to use.

Assignment implicitly will assign type based on the expression's value type, and make the scope local, if not DIM'd. References to a variable, prior to an implicit or explicit DIM, will have Alpha looking for the lowest scoped matching name.

I've scoured the help file and can not find any reference to the possibility of globally issuing an 'Option Strict' command. Is it possible to issue such a command, once?

Since every code piece is separate, there is no central place to put it. It would be nice if Alpha had an include for code, so that modules could be subsituted, but it does not.

In any event in relation to global variables (no matter which language) common sense should prevail regarding what names are used. You'd be asking for trouble if names such as temp, name, x, y, z etc. were used.

Absolutely, and good programming technique isolates code as much as possible from each other, which, for the most part, global variables are contrary to.

[milesjg]

Re: Global variables and dimensioning of same

Tom Cone Jr.

I'm a bit confused here. You said,

"DIM'ing the variable in later scripts tells those scripts that you are referencing the global. Otherwise, the later scripts will implicitly DIM the variable as LOCAL. Alpha Five permits duplicate variable names, with different variable scopes. You can have both a global var and a local var with the same name. The rule I follow is simple: if the var is not DIM'd in the current script it's LOCAL."

If I place a script in the onpush event for a button with the line,

Dim Global xray as N = 100

in the script, and in the onpush for a second button a script that says,

xray = 50
debug(1)

then press the first button then the second, debug shows the local variable frame is empty. The global shows xray = 50.
Likewise if I place the two lines without placing them in scripts. The same if the scripts are run in the interactive then xray is checked with global/local_variables().xray. The same applies to shared. Only by using Dim xray in script2 can I get the local and global frame to show xray (with their respective values). What "configuration" of scripts "implicitly dims" a local varible once it has been declared shared or global.?

[csda1]

Re: Global variables and dimensioning of same

What "configuration" of scripts "implicitly dims" a local varible once it has been declared shared or global.?

If you read my variable usage tips, it explains this.

There is no implicit DIM of a local variable if any variable of the same name currently exists at the Shared or Global. However, DIM varname as vartype does explicitly dimension the variable as Local, or the current pointer space of the WITH if used within a WITH/END WITH pair.

[Tom Cone Jr]

Re: Global variables and dimensioning of same

James, I'm sorry to have caused a bit of confusion here. I haven't seen the "promotion" of undim'd global variables before. Probably because I'm careful to explicitly dim the var global in each script that uses it. Ira's tips document explains what you're seeing. In my own work I explicitly dim shared and global vars whenever I use them. A practice that has seemed counter-intuitive to folks coming to xbasic from other languages, but a practice that has stood me in good stead over the years. --tom

[Steve T]

Re: Global variables and dimensioning of same

DIM'ing the variable in later scripts tells those scripts that you are referencing the global. Otherwise, the later scripts will implicitly DIM the variable as LOCAL. Alpha Five permits duplicate variable names, with different variable scopes. You can have both a global var and a local var with the same name. The rule I follow is simple: if the var is not DIM'd in the current script it's LOCAL.

Tom, I just need to address this further. It appears to me that the dimensioning of variables and the associated scoping, is in the main, similar, if not the same, as it is in other languages (VBA, Real Basic).

I believe the intent of your post is that if a variable is dim'ed in a function then it is implicitly defined as a local variable. If the keyword Global or Shared is also used in the dim line then it's not local. I accept this.

The point of my original post was why dimension an already dimensioned global variable. If the global variable is to be used in another function, then there is no need to re-dimension it. I've tested this and it works as expected. Granted, re-dimensioning the variable as global also works. I was simply querying why bother re-dimensioning.

Ira's example of the global variable name 'WOY' is interesting but whether this particular variable name is continually re-dimensioned (as global) or not does not alter the fact there is a problem with the WOY global variable name.

Prior to hitting the 'Submit Reply' button I read and re-read the above and I'm wondering whether we're going around in circles? I'll submit it anyway.

[Tom Cone Jr]

Re: Global variables and dimensioning of same

I was simply querying why bother re-dimensioning.

I suppose, strictly speaking, it's not necessary. If you keep better track of the variables scattered across your application than I am able to do then yes you could save a few keystrokes.

[csda1]

Re: Global variables and dimensioning of same

Hi Steve,

The point of my original post was why dimension an already dimensioned global variable. If the global variable is to be used in another function, then there is no need to re-dimension it. I've tested this and it works as expected. Granted, re-dimensioning the variable as global also works. I was simply querying why bother re-dimensioning.

For Globals that are already dimensioned in CODE THAT HAS BEEN EXECUTED, this is true, you could skip the line of code that dimensions it in other code. If the variable name is not dimensioned local or shared in the current code, then any accesses in the current code will find the global variable

But suppose you reuse this current code somewhere else (typically this current code would be a UDF function that was being used in a new place). Can you guarantee that the code that DIM's the variable global has been executed? If it was in the AUTOEXEC, probably yes. Pretty much anywhere else, maybe not?

Also, should you use reuse the variable name in the current code without realizing you have a global variable of the same name used in other code pieces, you will step on your own global code name's value, if you don't DIM the variable in the current code as something other than Global.

Ira's example of the global variable name 'WOY' is interesting but whether this particular variable name is continually re-dimensioned (as global) or not does not alter the fact there is a problem with the WOY global variable name.

The point was that WOY was never DIM'd at all in the Alpha Five built-in function, and that it could assume (and modify) any global or shared variable of the same name previously set in ANY CODE! WOY is not a likely choice for a variable name (unless writing functions that inolve weeks and years), however, imagine the damage had it been the variable name TEMP.

Alpha has 1 million + lines of internal XBasic code, that are not going to be updated anytime soon, to correct this DIM issue throughout. Doing it would, in itself, create many errors (and trust me, I know, as I've have gone back and DIM'd everything in my 80K plus lines of code a couple of years back).

And can you be 100% positive that any Add-in program or utility not from Alpha Software, DIM's all their variables so they don't step on yours? You can't! (well at least if they are not mine :D )

When you can, you want all code to be as independent from all other code, to increase reliability of the design. You want the code to stand totally by itself and be rock solid, or as I coined, a software "island of stability".