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 <[EMAIL PROTECTED]>
To: How to use Revolution <[email protected]>
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 
[EMAIL PROTECTED]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences: 
http://lists.runrev.com/mailman/listinfo/use-revolution 

_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to