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.
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.
--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software | http://www.hyperactivesw.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
