destroyStack, was: Stack Switching Question

[Richard Gaskin]

Robert Brenstein wrote:
>>>
>>> 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.
> 
> I am not sure that it is covered. Unless you mean than when I open a 
> stack, then I have to close it, then load to have it in memory again? 
> That would be too much ado. I am referring to a case when I open (not 
> load) a stack and then close it but want to keep it in memory since I 
> plan to reuse it (possibly re-show to user).
> 
> I think that ambiguity arises, at least partially, from having stack and 
> window being more or less synonyms, although they are not really quite 
> the same.

Quite, esp. given that we also have a destroyWindow property. :)

I think all Paul's suggesting is that two things happen:

1. Both stay-resident-on-close and purge-from-memory-on-close behaviors 
remain available as they are now, but the default would be 
purge-from-memory-on-close.

2. Introduce explicit commands for managing whether stacks are in memory 
or not, as opposed to the current situation which is wrought with 
inconsistencies (destroyStack only applies to stacks that are opened, 
but not those we merely read properties from without opening, and 
deleteStack sometimes purges stacks and at other times actually deletes 
the physical stack).

Whether the default behavior is changed, I think we all agree that some 
form of explicit control over what's in memory and what's not would be 
desirable.

And stepping back to look at the big picture, I doubt any of this will 
have much effect for quite some time anyway if at all, since there are 
many, many bigger fish to fry in the meantime.  So while it may be 
enjoyable conversation, I don't think we need to get too worried about 
any impending change on this anytime soon. :)

--
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com