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.
_______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
