destroyStack, was: Stack Switching Question

[Robert Brenstein]

>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.

Robert Brenstein