global problems

[Chipp Walters]

Sure,

here's a good example of exactly what you're talking about.

I have a splashscreen stack which manages updates via my own MagicCarpet 
Auto-update application architecture. It creates a global from a 
download URL prefs file for the domain where the stack and all the 
plugins reside, then downloads the main stack updates, etc. then closes 
itself. The 'main' stack now uses the same global to download the plugin 
stacks. Since there is no reference from to the splashscreen stack (it's 
closed) the global works just great!

Locals can have problems too. If you use script locals (locals declared 
outside a handler at the script level), and edit the script, the local 
will disappear the next time the script is run. I have a 'checkLocals' 
handler in my scripts for just that occasion. If it sees locals aren't 
declared, it reinitializes them. Though, I never expect to see a problem 
in runtime, it sure helps debugging during development.

Mark, I believe it's a matter of programming style. Many of us that use 
globals, understand their benefits and work with them to that advantage. 
IMO, your arguments against them seem to be primarily style-oriented and 
probably a function of your experience and prevailing disposition to 
more strictly typed languages. For those of us who've been programming 
Xtalks for umpteen years, they're second nature.

best,

Chipp

Mark Wieder wrote:

> And I still can't imagine a scenario in which you would want a global
> left over from a previous stack *only for that session*. I'll warrant
> that I may still be missing something VERY basic, but it still makes
> no sense to me.