Mark, globals are best used as "environment" variables. Not as persistent storage. Your example shows that if stack b opens and fails to work with a global, you didn't set a pre-requisite (nor a check) for xyz's conformity... that's asking for trouble.
If stack B had this check, it could then as stack A to fill in xyz to later use it. In another case, if you close stack A and delete xyz without cheking if another stack could still use it, implies a fault in the logic of the program... So one solution in this case, would be to tell stack B to look into a custom property which stack A could preset for stack B before close. Seems like a shoot-yourself-in-your-own foot script to me ;) > no... I declare globals sometimes thinking I'll need them for > cross-stack variables, then usually rethink things and can do without > them. But then they're still in memory causing trouble. I've used dozens of globals in XOS for 15 years without ONE problem... creating them on the fly, closing stacks, etc... but one thing i do always is to check first for existence and validity... with that, you've got yourself a lifesaver for every occasion... And if i open a stack that requires a specific global, it checks first to make sure that it is properly initialized or that it knows how to initialize it or to call the stack that will. programming is a process... cheers Xavier [EMAIL PROTECTED] wrote on 02/08/2005 08:37:43: > Brian- > > Monday, August 1, 2005, 6:56:19 PM, you wrote: > > > For me, the rationale is simple: globals are the ONLY way to have data > > which is _not_ stack specific. As such, closing or modifying a stack > > should never delete global data. > > I still don't get this. Can you give me an example of something you'd > declare as a global and *want* it to stick around when the stack that > declared it is closed? > > > Perhaps what you're really looking for is a stack-level local variable? > > no... I declare globals sometimes thinking I'll need them for > cross-stack variables, then usually rethink things and can do without > them. But then they're still in memory causing trouble. > > > I'm thinking the seeming oddity of the situation has something to do > > with the loose restrictions on declarations in xTalk, and the runtime > > nature. In other languages, if you removed all references to a global > > and recompiled, of course it would disappear...? > > ...which is what I expected to happen here... my bad. > > Here's a problem scenario as a gedanken-experiment: > > Open stack A > stack A has the global gXYZ > *and* puts a value into gXYZ > finish working with stack A, close and remove from memory > > Open stack B > stack B also declared global gXYZ > now stack B is open and has a value in gXYZ > but never initializes it > exit the IDE > > Relaunch the IDE > Open stack B > now stack B has no value in gXYZ > and some functions fail that rely on gXYZ > > -- > -Mark Wieder > [EMAIL PROTECTED] > > _______________________________________________ > 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 ----------------------------------------- Visit us at http://www.clearstream.com IMPORTANT MESSAGE Internet communications are not secure and therefore Clearstream International does not accept legal responsibility for the contents of this message. The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any views expressed in this e-mail are those of the individual sender, except where the sender specifically states them to be the views of Clearstream International or of any of its affiliates or subsidiaries. END OF DISCLAIMER _______________________________________________ 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
