Global variables in scripting

[admin]

I just implemented global vars using the keyword "global" similar to PHP.

Code: Select all

global $a = "X";

However, when playing with it, I found a number of possible problems and confusions: Can local and global vars have the same name and live independently? Which one dominates the other if there are same-named vars? Can a local var be globalized later in the script? Etc. ...

Then saw a way to solve all these possible problems quite elegantly! Forget about the keyword "global" but simply use a special naming convention for global vars!

For example preprending $g_:

Code: Select all

$g_name = "X"; //global var
$name  = "X"; //local var.

As an additional advantage, code would be easier readable and maintainable, since you see at once whether your variable is global or local.

Did I overlook anything, or is it okay to deviate from PHP in this matter?

[TheQwerty]

I seem to remember suggesting something similar when this was last discussed, so I still don't have a problem with it.

Then I thought using a different starting character might have been appropriate ($a = local; &a = global; or similar), but "$g_" also works.

[j_c_hallgren]

I'm not a PHP'r or a script'r but from the sidelines, I'd ask if simply using "_" as prefix (as in $_xxx) would be possible to distinguish globals...that might be simpler to remember, and also keep variables named more to user wish.

[jacky]

yay for global vars!!

I'm not a PHP'r or a script'r but from the sidelines, I'd ask if simply using "_" as prefix (as in $_xxx) would be possible to distinguish globals...that might be simpler to remember, and also keep variables named more to user wish.

My first thought as well, but $_foo is already a valid name for a (local) user variable, so that might cause "compatibility issues" ?

But really, in all fairness, $g_foo is today a 100% valid local user variable as well, and I would definitely prefer to have $local and $_global as well (plus in PHP there are some special (super-global) variables wiht names like $_SERVER so it would even not be that deviating from PHP... kinda).

[admin]

yay for global vars!!

I'm not a PHP'r or a script'r but from the sidelines, I'd ask if simply using "_" as prefix (as in $_xxx) would be possible to distinguish globals...that might be simpler to remember, and also keep variables named more to user wish.

My first thought as well, but $_foo is already a valid name for a (local) user variable, so that might cause "compatibility issues" ?

But really, in all fairness, $g_foo is today a 100% valid local user variable as well, and I would definitely prefer to have $local and $_global as well (plus in PHP there are some special (super-global) variables wiht names like $_SERVER so it would even not be that deviating from PHP... kinda).

I don't see anything against $_.

What I liked about $g_ is that the slot might be used for other uses/letters like $m_, $p_ etc. (not having any great idea ATM what these should be...), so it might be reserved for future uses, and using a name other than $g_, e.g. "$k_name" would be illegal now (preventing future compatibility issues...). But OTOH, local versus global seems to be a distinction clear and general enough to justify a bold representation like $[letter]... versus $_[letter]... so I think yes, it's okay!

[eurytos]

What about adding -scope or something similar to the definition?

Code: Select all

$name = "X" -scope global; //global var.
$name  = "X" -scope local; //local var.  <-- default
$name  = "X" -scope private; //private var.

maybe type would be better?

Code: Select all

$name = "X" -type global; //global var.
$name  = "X" -type local; //local var.  <-- default
$name  = "X" -type private; //private var.
$name  = "X" -type constant; //constant var.
$name  = "X" -type readonly; //readonly var.

I also like this:

Code: Select all

$Global:name = "X"; //global var.
$Local:name  = "X"; //local var.  <-- default
$Private:name  = "X"; //private var.
$Constant:name  = "X"; //constant var.
$Readonly:name  = "X"; //readonly var.

You would refer to the variable the same as now:

Code: Select all

$name

I don't really like the idea of the syntax of a variable determining it's type. I like to keep my own (screwed up and un-readable by anyone else) because it keeps me from getting confused. Plus using the above methods leaves the future open and you don't need to worry about anyone that already has variables named $g_myvariable, etc.

Code: Select all

set $Constant:foo, "foo";
msg "$foo";

[RalphM]

What I liked about $g_ is that the slot might be used for other uses/letters like $m_, $p_ etc. (not having any great idea ATM what these should be...), so it might be reserved for future uses, and using a name other than $g_, e.g. "$k_name" would be illegal now (preventing future compatibility issues...). But OTOH, local versus global seems to be a distinction clear and general enough to justify a bold representation like $[letter]... versus $_[letter]... so I think yes, it's okay!

I vote for your suggestion - sure makes scripts easier to read...

[admin]

What about adding -scope or something similar to the definition?

Code: Select all

$name = "X" -type global; //global var.
$name  = "X" -type local; //local var.  <-- default
$name  = "X" -type private; //private var.
$name  = "X" -type constant; //constant var.
$name  = "X" -type readonly; //readonly var.

I also like this:

Code: Select all

$Global:name = "X"; //global var.
$Local:name  = "X"; //local var.  <-- default
$Private:name  = "X"; //private var.
$Constant:name  = "X"; //constant var.
$Readonly:name  = "X"; //readonly var.

You would refer to the variable the same as now:

Code: Select all

$name

I don't really like the idea of the syntax of a variable determining it's type. I like to keep my own (screwed up and un-readable by anyone else) because it keeps me from getting confused. Plus using the above methods leaves the future open and you don't need to worry about anyone that already has variables named $g_myvariable, etc.

Code: Select all

set $Constant:foo, "foo";
msg "$foo";

As I said, I have already implemented a similar thing right now...

Code: Select all

global $name = "X";

... a syntax which is usable for all of your suggestions. In principle I like to be open for later enhancements, of course, and I like the explicitness and user-friendlyness of a statement like global $name = "X"; as opposed to $_name = "X";. Also this non-name-based scope definition allows the user to still do this...

Code: Select all

global $g_name = "X";

...so the point of code readability is a weak one.

So what speaks against global $name = "X";? Maybe not much, but you have to be aware of the following points:

Code: Select all

// -- main procedure ---
// create/set a global var
global $name = "X";
// this will refer to the global var
echo $name; // = "X"
// create/set a local var
$name = "Y";
// this will now refer to the local var!!!
echo $name; // = "Y"
...
// -- sub procedure ---
// this will refer to the global var
echo $name; // = "X"
// this will create/set a local var of the same name!
$name = "Y";
// you need to use the global keyword everytime you alter the value of a global var
global $name = "X2";
// but there is no way to refer to (i.e. use) the global var $name if there is a local var $name because local vars overwrite global vars
// this will now refer to the local var!!!
echo $name; // = "Y"

You see, once you use same-named global and local vars things get confusing, so it must be strongly recommended to not do this! Which is why I got the idea of enforcing to use different names...

[admin]

PS: I read through http://www.php.net/manual/en/language.v ... .scope.php and my impression is that the PHP way leads to confusion here and there.

Compared to this, my way of prefixing $g_ is clear and fool-proof as can be. And yes, I prefer to use $g_ instead of just $_. It's a touch more explicit, and also kind of reminds you that globals are bad. This might be a useful reminder later when scripting supports passing arguments to subs and functions...

[eurytos]

PS: I read through http://www.php.net/manual/en/language.v ... .scope.php and my impression is that the PHP way leads to confusion here and there.

Compared to this, my way of prefixing $g_ is clear and fool-proof as can be. And yes, I prefer to use $g_ instead of just $_. It's a touch more explicit, and also kind of reminds you that globals are bad. This might be a useful reminder later when scripting supports passing arguments to subs and functions...

I think you should go with the method you prefer, I was just trying to be helpful and provide some alternatives. I do agree that $g_ is better than $_ because it gives you the ability to expand on the idea like you mentioned earlier.

[admin]

PS: I read through http://www.php.net/manual/en/language.v ... .scope.php and my impression is that the PHP way leads to confusion here and there.

Compared to this, my way of prefixing $g_ is clear and fool-proof as can be. And yes, I prefer to use $g_ instead of just $_. It's a touch more explicit, and also kind of reminds you that globals are bad. This might be a useful reminder later when scripting supports passing arguments to subs and functions...

I think you should go with the method you prefer, I was just trying to be helpful and provide some alternatives. I do agree that $g_ is better than $_ because it gives you the ability to expand on the idea like you mentioned earlier.

I decided that this topic needs deeper reflection. I will look back at global variables later.

[PeterH]

I think the method with $g_ as prefix is strange and unusual.
But nevertheless I like it, too!

[jacky]

Compared to this, my way of prefixing $g_ is clear and fool-proof as can be. And yes, I prefer to use $g_ instead of just $_. It's a touch more explicit, and also kind of reminds you that globals are bad.

Now why would you say that, global vars will be great and allow me to remove lots of unnecessary getkey/setkey and copytext/<clipboard>, thus also giving me back my status messages! That's not bad at all!

And I'm not sure what confusions you were referring to, I feel PHP's way is quite easy, and even better actually, because no variable is ever global, it's only global when you want it to be. That means imagine a script using a global var $foo and then loading another script also using $foo, that second script could use $foo without it being a global var, it can decide whether it will be local or global.

Sure, variables don't say whether or not they're global by their names, but is that really a problem ? Everyone can still decides to make it that way... Look at your PHP or VB code and tell me, can you tell which vars are global and which are local just by their names ? Answers might be yes, but only if you decided to use a rule for it, shall it be a prefix, a suffix, uppercase for global and lowercase for local, etc
Just like maybe your variables are names "nbSelectedItems" or just "d", no one forces you to use names that actually allow to easily "understand" what the variable is, but no one prevents you from doing it either.

As for your original questions, I think they all have easy and logical/"natural" answers :
- Can local and global vars have the same name and live independently?
hm.. okay, yes and no. A variable is either local or global, and you obviously can't have two variables by the same name. But a script can use local vars with names of existing global vars without problem/conflict, since it doesn't access those (global vars) unless it asks for it (using command global), and then it will use the specified global var, so no more local one.

- Which one dominates the other if there are same-named vars?
There's no dominance. A script using $foo uses a local var $foo until a call to global for $foo is trigered. Then, local $foo is unset and global $foo is "loaded"/used instead.

- Can a local var be globalized later in the script?
Sure, why not.

Code: Select all

"script1"
  $foo = 4; // local
  global $foo; // now $foo is global, becomes empty (assuming nothing created a global $foo before obviously)
  $foo = 8; // global
  sub script2;
  msg $foo; // 16 (global)

"script2"
  msg $foo; // nothing/empty, it's local
  $foo = 15; // local
  global $foo; // global, value is now 8
  $foo = 16; // global

My order of preference would be:
1. no name-specific but command global (PHP-like)
2. $_name
3. $g_name

[graham]

Jacky concluded:
My order of preference would be:
1. no name-specific but command global (PHP-like)
2. $_name
3. $g_name

I was, until this convinced $g_name was a simple way forward but in line with good programming practice the explicit naming of scope makes identification easy and avoids potential mistakes.

Yes, I second Jack'y preferences

[eurytos]

Jacky concluded:
My order of preference would be:
1. no name-specific but command global (PHP-like)
2. $_name
3. $g_name

I was, until this convinced $g_name was a simple way forward but in line with good programming practice the explicit naming of scope makes identification easy and avoids potential mistakes.

Yes, I second Jack'y preferences

I like number one, but would switch two and three