Stack Switching Question

[simplsol at aol.com]

Richard, Jacque, et. al.,
By "destroyStack" don't we always mean "purge stack"?
PL

-----Original Message-----
From: Richard Gaskin <ambassador at fourthworld.com>
To: How to use Revolution <use-revolution at lists.runrev.com>
Sent: Wed, 05 Oct 2005 20:19:01 -0700
Subject: Re: Stack Switching Question

   J. Landman Gay wrote: 
 > Dave Cragg wrote: 
 > >> 
 >> On 5 Oct 2005, at 21:04, Richard Gaskin wrote: 
 >> 
 >>> J. Landman Gay wrote: 
 >>> 
 >>>> Richard Gaskin wrote: 
 >>>> 
  >>>>> I used the file name form to illustrate another difference 
between >>>>> HC and Rev: while you would indeed need to open a stack 
in HC in >>>>> order to get stuff out of it, in Rev you can get 
property values >>>>> of objects in unopened stacks. When you do that 
the engine reads >>>>> the file into memory to access what's being 
requested; if the >>>>> stack has been accessed before it'll stay in 
memory (unless you >>>>> turn on the stack's destroyStack property), so 
subsequent accesses >>>>> will be lightning fast. 
 >>>>> 
  >>>> Just an addendum: Actually, I've been using this technique on 
 >>>> multiple stacks, and found that once accessed, the stack stays 
open >>>> until you explicitly close it regardless of its destroystack 
 >>>> settings. I found this out after I accessed data from a ton of 
 >>>> external stacks and then discovered them all open later on. I had 
 >>>> to specifically close them to remove them from RAM (their >>>> 
destroystack was true, so that did the trick.) If an accessed stack 
 >>>> has its destroystack set to false, just closing it won't be 
enough, >>>> the script will have to delete it as well. (I know you 
already know >>>> that, Richard, just mentioning it for completeness.) 
 >>>> 
 >>> 
 >>> 
  >>> Actually I didn't know that. Is that a bug? It rather invalidates 
>>> the destroyStack property, no? 
 >>> 
 >> 
 >> I think we could debate that one for a month or two. :-) 
 >> 
  >> I suppose the destroyStack is intended to apply when a stack is >> 
closed, and therefore has been explicitly opened earlier. Referencing 
>> an external stack isn't the same as opening it. 
  > > > To me, it is like opening a stack invisibly without any system 
messages. > At least, that's how I think of it. Destroystack applies to 
referenced > stacks just as it does to stacked opened other ways -- 
when a script > closes them, they are removed from memory if that 
property is set to > true. Otherwise, a script must issue a "delete 
stack" command to get rid > of it. 
 > 
  >> Like Jacque, I've been caught out with stacks in memory when I'd 
long >> forgotten about. However, one practical problem for the engine 
to >> overcome would be to determine when it should purge the stack. >> 
Typically, when I reference an external stack, I'm likely to make a >> 
few references to it within a handler. Having to reload the stack for 
 >> each reference could introduce an overhead. (Perhaps referenced >> 
stacks should be purged when any currently running handlers finish.) 
 >> 
  >> Meanwhile, I try to remember to specifically delete each externally 
>> referenced stack. 
  > > > After some thought, I think the current implementation is 
correct. > Destroystack doesn't (and shouldn't) control whether or not 
a stack > closes, it just manages the stack's behavior when it does 
close. 
 
  Of course but the stack is never truly open, so it's not about closing 
at all but about purging, something we don't have a token for. 
 
  > In my situation, I sometimes need to refer to a stack repeatedly 
across > handlers, and other times only need it once. I don't think I 
want the > engine deciding for me when the stack should close, I'd 
rather control > that myself. As long as I know that referencing a 
stack loads it into > memory, closing it later at my convenience isn't 
a problem. 
 
  I'm on the fence on this one, esp. given that "delete stack" sometimes 
purges a stack and at other times actually deletes a stack. 
 
  If we had a "purge stack" command I'd happily go along with leaving 
control in the hands of the developer. 
 
  Maybe we could add "purge stack" at the same time as we rename the 
unnecessarily alarming "destroyStack" property to something more 
closely related to what it does. :) 
 
 -- 
  Richard Gaskin 
  Managing Editor, revJournal 
  _______________________________________________________ 
  Rev tips, tutorials and more: http://www.revJournal.com 
 _______________________________________________ 
 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