[SOLVED]-“Bad” global variables—Using alternatives

[anmldr]

In LC Lessons .pdf
Subject: Global variable alternatives
Under the heading, “Use local variables instead”

It says “For example the getState handler can perform verification of the new value.”

How do you verify the new value of a local variable?

It continues after the above quote, “It's also possible to hide the details of how the data is stored, allowing you to change it in the future. You could even store it in an external preferences file rather than a variable.”

How is this accomplished?

Linda

[dunbarx]

Hi.

i am not sure what you are asking. I have not looked at the lesson.

Anyway, let's say you have a bunch of command and function handlers in a script. Some of those handlers likely call others.

Any variable's contents will not survive outside its own handler. You can pass its contents explicitly in a parameter to another handler of course. But its contents will disappear once the enclosing handler ends.

But if you declare that variable as "local" at the top of the script, changing it into a "script local" variable, then its contents can be "retrieved" by any other handler in that script in any single running "procedure". By "procedure" I mean any single"run" of handlers, where one calls another, perhaps back and forth or whatever, ad infinitum. But when the procedure ends, so does the ability of LC to remember what it had in it.

If you declare the variable as "global", however, then its contents are remembered universally by LC itself, and any script anywhere, including procedures that start later on from somewhere else, can access its contents, as long as the session itself does not end.

So there is a hierarchy of "permanence" with the three types of variables, and there are good reasons for the differences.

Beyond globals, you can save the contents of a variable in a custom property, or even a field or button, which will survive sessions. These are stored permanently inside the stack. You might consider that a fourth level, though we are now out of the variable world entirely.

And yes, you can even store data in an external file for later retrieval, and now we are even farther away from the variable world.

Is this of any value?

Craig

[dunbarx]

There was a movement, years ago, that gave global variables a bad name. Something about taking up memory, having to be declared in every script that needed them, whatever. Custom properties were seen as better alternatives. Perhaps that is what the lesson implied?

I use globals, but use custom properties much more. These do not have to be declared explicitly in each script, though you certainly have to remember what they are and what they contain. They have the advantage that they can be named very descriptively, like the "usualSuspects", which helps me know when I need to reference them. And they survive sessions, which is very convenient.

Ultimately, it is much a matter of style, with each "level" of data "memory" having its place.

Craig

[bogs]

Craig,
Linda is referring to this lesson - https://lessons.livecode.com/m/4071/l/1 ... -variables

There was a movement, years ago, that gave global variables a bad name. Something about taking up memory, having to be declared in every script that needed them, whatever.

I remember the memory issues, but for different languages (was before I started using Lc). The article speaks specifically to 4.5 points ...

It often seems convenient to use globals as they generally require less initial coding than the alternatives, and seem simpler at first. Their disadvantages tend to emerge later on when something goes wrong and you are trying to debug the program, or when trying to change the code in the future. Here are what I consider the main problems with globals in LiveCode (and in all other languages):

1. Global Scope - Because global variables are not associated with any object, they can be accessed by any part of the program. This makes it difficult to figure out which parts of the program depend on a particular global, and what effects changing it might have.

2. No Access Control - Global variables can also be changed by any part of the program. This means that if the program breaks because a global has the wrong value, it can be hard to track down how this happened. This is a debugging headache, but can also cause security problems in some applications.

3. Lack of Encapsulation - If alternatives to global variables are used, it tends to lead to more modular code, as handlers will be grouped depending on which data sources they use. Extensive use of global variables often leads to monolithic scripts.

4. Namespace Problems - The scope of global variables means that each one must have a unique name in the context of the entire program. It is quite easy when coming back to the code after a few months to accidentally re-use the same global name for a totally different purpose. This can be very painful to track down. This namespace problem can also mean it's hard to come up with good, concise names for your global variables.

Globals are not always bad. Sometimes their convenience and efficiency can outweigh the above drawbacks. However, I have developed using LiveCode for 5 years and have only very occasionally used global variables in my own code.

The main problem I see with globals is very much a mix of the first and second points here, mainly that because any part of the program can change their value, it can lead you down a rabbit hole chasing down where something went wrong. That, and I'm not really sure they are needed, especially in this language where you can set a custom property that can be globally reached from anything else in the program.

However, my personal opinion on this topic isn't part of the question, and I have to get to bed soon

It says “For example the getState handler can perform verification of the new value.”

How do you verify the new value of a local variable?

In the example I *think* you are referring too, the code is actually thus -

Code: Select all

local sState ## you have declared a local variable...

command setState pValue --- this command inserts a value into the local variable...
	put pValue into sState
end setState

function getState -- this function is verifying the value put into the variable in the previous command...
	return sState
end getState

It continues after the above quote, “It's also possible to hide the details of how the data is stored, allowing you to change it in the future. You could even store it in an external preferences file rather than a variable.

I'm not sure I understand which part of that your questioning?

If you mean how do you store it in an external preference file, that simply means you write the variable out, probably something like (psuedo code) -

Code: Select all

on closeRequest -- your closing the program...
	put sState into url("File:{path to your preference file}"
end closeRequest 

The above would save out the variable to (most likely) a text file, but really you could use almost any format, binary for instance, xml, etc.

If you meant something else, feel free to question it

[FourthWorld]

Not a big fan of absolutist dogma, personally.

There's a reason nearly every programming language -- including LiveCode -- offers global variables, and it isn't to mislead you.

At some point we need to revise that Lesson to offer a more balanced view of globals and their alternatives.

In the meantime, you may find this covers it reasonably well:

http://forums.livecode.com/viewtopic.ph ... 57#p129457

[bogs]

I agree, nothing in this world is an 'absolute' rule, and as that lesson states, there certainly are times when globals are appropriate, or even desirable, and like you said, I haven't run across the language yet that doesn't offer them, even assembly.

They just are not the first tool in the box I run for, for the reasons stated. While I haven't been using Lc for all that long (relatively speaking), even in the previous languages I did use I tended to eschew them in favor of alternate solutions.

As far as the lesson goes, I'm not sure it needs revision, it's title after all is "What are the alternatives to using globals", and there is at least one other lesson that is solely about using globals. The lesson accomplishes what is in the title and gives you room to think about your alternatives.

[anmldr]

Thank you everyone. I think that between all of you, the questions were answered fully.

Linda