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