global problems

[xbury.cs at clearstream.com]

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

use-revolution-bounces at lists.runrev.com 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
>  mwieder at ahsoftware.net
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> 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