Unpopularity of global variables - why?

[Ken Ray]

On Oct 12, 2012, at 9:13 PM, J. Landman Gay wrote:

> On 10/12/12 6:50 PM, Timothy Miller wrote:
>> 
>> I consistently put empty into all unused globals when a script starts.
> 
> Unlike HyperCard, in LiveCode you can actually delete them entirely:
> 
>  delete global gMyGlobal
> 
> I don't have a particular hatred for globals either, you just have to know how to be careful with them. On the other hand, I don't think I've needed one now for years but if I did, I wouldn't hesitate to use it. They are faster and more convenient than a property or a handler, but their main advantage is that they aren't tied to any particular stack. That's a big advantage, even if you don't need it very often.

Agreed - I use globals, but give them unique names to avoid kaboshing anyone else's globals (like "gSTS_FillInTheBlank"). To *me* the main downside with them is that you have to declare them in any script that wants to use them… so they're not *truly* global until you set up a connection to them. Personally I'd find globals more useful if once declared and set that they didn't need to be declared again to be used, but if that were to happen, I'd probably want to see Bob's suggestion (applicaton globals vs. stack globals) or the equivalent put into place to apply a scope to them.

But all the options have their pros and cons:

Globals:
	Pros: Easy to use, available everywhere, resides only in memory (so they're disposed of as soon as the engine quits); can be multidimensional arrays (which can cut down on the number of actual globals you use, BTW)
	Cons: Easy to kabosh if not careful, you need to declare them in every script that uses them

Functions: 
	Pros: Only need to be created once at design time and can be called from everywhere that has access; more flexibility (it can take parameters to adjust the returned value so you could simulate multiple dimensions by using parameters)
	Cons: The function needs to be in the available message path, which means that you'd need to use a frontscript/backscript/library to make it available to more than a single mainstack (and if you *do* that, you need to be careful of naming conventions because someone else might kabosh your function name); the actual data that is returned has to be stored somewhere if it's not just a calculation (although you can use a script local in the script that has the function so that it isn't permanently stored anywhere)

Custom Props:
	Pros: Is "stuck" to an object (like a stack), so you know the value is specific to that object (e.g. the uVersion of <stack> vs. gMyStackVersion);  only needs to be created once at design time; can be reached from anywhere so long as the object it's attached to is available
	Cons: *Much* easier to accidentally store permanently what should be a temporary change to a value (for stacks that need to call "save" for any reason); more difficult to use (gMyGlobal vs. "the uWidgetType of btn 3 of card 123 of stack 'WhoTheHellCares'")

I'm sure there's more, but those are what popped into my head.  :D


Ken Ray
Sons of Thunder Software, Inc.
Email: kray at sonsothunder.com
Web Site: http://www.sonsothunder.com/