destroyStack, was: Stack Switching Question

simplsol at aol.com simplsol at aol.com
Thu Oct 6 12:25:54 EDT 2005


Richard,
  I was also concerned about the legacy apps. My first thought was to 
allow "load by reference" for some period of time (for example all 
shipments of Rev. delivered after January 2007 would require the new 
behavior). But it may be that only a very small group of current Rev 
programmers are even aware of this feature. I'd like to hear from them 
before finalizing any recommendations.
  I also believe the "load stack" command would address Robert's 
concerns.
 Can we kill "destroyStack" in my lifetime?
 Paul Looney

 -----Original Message-----
 From: Richard Gaskin <ambassador at fourthworld.com>
 To: How to use Revolution <use-revolution at lists.runrev.com>
 Sent: Thu, 06 Oct 2005 07:17:58 -0700
 Subject: Re: destroyStack, was: Stack Switching Question

 Robert Brenstein wrote: 
 >> Jeanne, 
 >> It got 5 of my votes as well. 
 >> But I think there is more confusion here. 
 >> A 
  >> I believe Open Stack and Close Stack should be symmetrical. In 
other >> words, Close Stack should reverse the results of Open Stack. 
Open >> Stack 1. loads the stack into memory, 2. makes the stack 
visible on >> the screen, and 3. locks other users out of the stack. 
Close Stack >> should (in opposite order) 1. release the stack to the 
next user, 2. >> remove the stack image from the screen, and 3. purge 
the stack from >> memory. Close Stack should always purge, there should 
be no >> "destroyStack" or "purgeOnClose" option. This would be 
logical, >> elegant, consistent, predictable, simpler, and visible (you 
would not >> end up with hidden stacks in memory that you didn't know 
were there). 
 >> B 
  >> In addition to a Purge, or Purge Main Stack command, I'd like to 
see >> a Load Stack command - symmetrical with purge. "Load" is short, 
 >> describes the operation, and is already used by Transcript for URLs. 
 >> Load Stack would place a copy of a stack in memory (without opening 
>> it), Purge Main Stack would remove it. 
 >> C 
  >> I believe stacks should only be put into memory by opening or 
loading >> - not by referencing. This would be logical, elegant, 
consistent, >> predictable, simpler, and visible. There is not (and 
should not be) a >> Dereference command! By being forced to load stacks 
before working on >> them we will always be reminded to purge them and 
we will not have >> stacks in memory which we put there unaware. 
 >> Let's bury "destroyStack" permanently. 
 >> Paul Looney 
  > > > Sounds good to me, Paul, but you need to accommodate closing 
stack > window as opposed to closing stack. We have now: 
 > > close with destroyStack off = close stack window 
  > close with destroyStack on = close stack window, remove stack from 
memory 
  > > We still need to be able to do the former. Hide stack comes to 
mind as a > solution, of course, but making a stack as invisible is now 
subtly > different than closing it without removal from memory. 
  
  If I understand Paul's suggestion correctly, I believe that's covered 
under his request for a "load" command. 
  
  His thinking is not unlike something we all go through learning Rev: 
in any other app closing a window ultimately purges the data presented 
in it from memory. 
  
  As much as I like (and often rely on) the current stay-resident 
behavior I wouldn't mind if it were optional, with the default being 
the more intuitive purge. 
  
  Of course backward compatibility is a whole other issue, so at best we 
might hope for some global flag to allow the old behavior to be 
sustained for legacy stacks without requiring an explicit "load". 
  
 -- 
  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 

  



More information about the use-livecode mailing list