Local Vs. Global Variables

[Kent Searight]

Hi all,

I've been using script variables in place of the majority of global fields I used in solutions developed prior to FM8. Recently I noticed that every time I've replaced a global field with a script variable, I've made the variable global also...which leads me to the question...

Is there ever a time when a local variable is superior to a global one?

I believe I have a good understanding of how each one behaves but I've yet to figure out why one would use a local variable over a global one.

Thanks in advance!

[Matt Klein]

Hi Kent -

As you probably know, the main difference between local and global variables is persistence. The local variable ceases to exist once the SCRIPT it is created in ends while global variable is persistent until the FILE in which it created is closed.

That said, I like to use local variables as much as possible mainly because I don't have to worry about the contents of them once the script is done. With global variables, even if you are not currently using it, it and it's contents are there taking up space. I don't really know how the variables are stored, whether it be in RAM or in temp files of some kind, but if it's in RAM then it could be performance hit. Also, if you use the same global variable throughout your solution to control behavior of scripts you may need to remember to clear the variable to avoid possible behavior you don't want.

In truth, I use global variables quite a bit and I have, much like yourself, replaced all the globals in my solutions with script variables except those globals needed for relationships. I just use local variables whenever it's possible to avoid worrying about maintaining the contents of a global variable.

It is worth stating that the contents of script variables are only usable in the File in which the variable was created. So, if you want to pass information between scripts in different files, globals or script parameters are the way to go.

[Ender]

Hi Kent,

I agree with Lwlgeorge, that I'd prefer to use local variables for local values; mostly as a cue that the variable is local to that script (and not set or referenced externally.)

A couple scenarios I can imagine where local variables would be needed is with nested looping scripts, where the same variable name is used as a counter, and with certain recursive scripts, where the previous value is needed after the recursive call. Granted, these can be done in other ways, but it's nice to have the option to keep the scope local.

[T-Square]

I'll chime in agreeing that local variables are to be preferred. In fact, a lot of programming guides will tell you that global variables are a distinct no-no.

A programmer cannot be certain about the state of a global variable, since any other process can modify the value. This makes debugging a veritable nightmare, and intermittent bugs are the worst to try and fix.

Local variables force a programmer to be disciplined about their use of variables; if a local variable isn't initialized before it is used, the program will usually crap out. While this might seem to be an impediment, it is far easier to determine the active state of a local variable than a global one.

Because Filemaker didn't support variables in scripts, or passing variables between them, FM programmers have had to make use of the actual database file to store these variables, which is IMHO not a good idea. But that was what we have had, so it was better than nothing.

David

[Ted S]

I always ask myself; do I need the value contained in the variable to be available beyond the current running script. If yes, then I use a global variable, if no, then I use local.

[Matt Klein]

I always ask myself; do I need the value contained in the variable to be available beyond the current running script. If yes, then I use a global variable, if no, then I use local.

I ask myself a similar question. The difference for me is whether or not it makes sense to pass the local variable to the sub-scripts in a script parameter. Of course, if you are talking about using beyond the current running script and it's subscripts, then I, like you, use global variables.

[Kent Searight]

Thanks to everyone for their excellent responses. They've helped me a lot :waytogo:

[Søren Dyhr]

Of course, if you are talking about using beyond the current running script and it's subscripts, then I, like you, use global variables.

Yes the threshold is the running script as object. However have I just learned something very very cool ...which at least I am going to put under scrutinization:

http://tokerud.typepad.com/filemaker/2005/11/filemaker_8_usi.html

...this will demand the use of $$'s

This will perhaps take recursive scripts to a very interesting level... bringing back sweet memories of "The Tower of Hanoi"

http://www.cut-the-knot.org/recurrence/hanoi.shtml

--sd

[comment]

Very interesting technique.

Of course, she's wasting the opportunity to pass another variable in the result of the calculation - which would then be available as the actual script parameter. But still very clever.

this will demand the use of $$'s

Hmmm... will it indeed?

MultiVariables8.fp7.zip

[Matt Klein]

Yup, I use the technique she describes all the time. I will often start a script with a Set Variable script step that actually sets a handful of variables based on current environmental conditions using the Let technique she describes.

That way, regardless of what happens in the script, whether it be changing fields or windows or whatever, I always no the state of the app when the user called the script. This really helps me to use the same script from multiple places and make decisions in the script and sub-scripts bases on where the user starts from.

[Matt Klein]

Very nice comment! I may just use that technique.

[Kent Searight]

[Matt Klein]

Sorry for the confusion. It is true that a local variable is only available to the script that creates it. What I was saying was that I ask myself does it make sense to pass the local variable as a script parameter of the sub-script.

This can be done by just passing the contents of the local variable as the script parameter or doing something like what comment's sample file does by passing a Let statement with local variables as text in the parameter and evaluating it in the subscript.

[Kent Searight]

Thanks for clearing that up, Matt. I get what you were saying now. And thanks for all your help!

Kent

[Kent Searight]

I looked over the web article Søren referred to and I believe I understand the basic idea of creating and defining script variables with the Let() function, in the script paramameter. At the risk of sounding like a dolt, I have to ask this question anyway because I believe you all to know FM extraordinarily well, and you seem to think this is a pretty significant technique.

The technique, as I see it, is just a different place to define and create script variables, i.e. in the script parameter. It is interesting, indeed, but I don't think I'm seeing the full potential of it. How could this "take recursive scripts to a new level", as Søren put it?

Thanks for your patience :

[Søren Dyhr]

How could this "take recursive scripts to a new level", as Søren put it?

I might have exaggerated the importance but the stacking behaviour of parameters for each call, makes it sometimes counterintuitive in my head at least ...never the less am I still trying guess where it as such has it's finest moments.

Another thing I still reaching out for to see the full potentials in is the parameter you can put in Exit Script[

The biggest problem you have with recursive scripts, which I initially believed were bygones with the introduction of variables, is to comment/document them enough to get the point month later when re-investigating the script again.

But I have a joy in thinking recursive solutions, which you also might notice the upload I made today. But beyond my joy, might there not be any need to use them.

--sd