Trevor DeVore wrote:
On Oct 31, 2006, at 7:59 AM, Richard Gaskin wrote:
That this would be the case with stacks whose destroyStack property
is FALSE makes sense, but when a stack's destroyStack is TRUE this
is inconsistent with other behaviors we've come to expect from the
engine.
...
I'm not sure I understand why a stack should not be brought into
memory and stay in memory until told otherwise when accessing it
using the complete filenmae. destroyStack docs state that it applies
when a stack is closed. Since the stack is never officially opened
(no go stack, no msg sent) it is not closed so in my mind it should
remain in memory.
By default it would work exactly as it does now.
By default, the engine creates stacks with their destroyStack property
set to false.
The destroyStack property is used to govern whether a stack remains in
memory when using "go" or "open", but it not honored when a property
within a stack is accessed.
By honoring the destroyStack property consistently, accessing properties
of stacks which have this set to true would cause the engine to read the
file, obtain the data, dispose of the copy of the stack in memory, and
return the value requested.
--
Richard Gaskin
Fourth World Media Corporation
___________________________________________________________
[EMAIL PROTECTED] http://www.FourthWorld.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
