Rules governing stack purging
ambassador at fourthworld.com
Tue Oct 31 14:41:15 CST 2006
Dave Cragg wrote:
> On 31 Oct 2006, at 19:27, Richard Gaskin wrote:
>> By honoring the destroyStack property consistently with its
>> behavior for "go" and "open", we would gain greater certainty about
>> what's in memory.
> Perhaps we see destroyStack differently. Like Trevor, I see it as
> something that comes into effect when you close a stack. In the cases
> we're discussing, no specific "close stack" is performed. So why
> should the destroyStack property come into play?
What can be in memory that wasn't opened?
Closing is the compliment to opening. If something is in memory it got
there somehow; the stackfile was opened and read into memory.
Accessing a property is of course not the same as issuing an "open" or
"go" command, leaving one to surmise that the property is accessed, the
data returned, and the stack data from which it was parsed is safely
But that's not the case: it turns out that the engine treats property
accesses as another form of "open" or "go", in almost all respects
except that the stack is not listed in windows().
As long as the engine is leaving around data we didn't ask for, all I'm
suggesting is that we might have a more consistent means of managing it.
I think it's safe to say that we have near unanimity on the suggestion
to clean up the nomenclature surrounding memory management of stacks
("delete stack" being dangerously ambiguous and "destroyStack" being
If we consider introducing some more descriptive synonym for what is
currently "destroyStack" and depricate the latter in the docs while
still supporting it, and adding a "purge stack" command as Jeanne
requested some time ago, we might at that time also consider the broader
implications of how such things fit together conceptually.
While it's true that some seasoned Transcripters have long ago grasped
how merely accessing a property will cause a stack to be left in memory,
is it the case that new users expect this as well?
>> Under what circumstances do you want to save changes to a stack
>> that you neither open nor have its destroyStack left in its default
> As I said, I don't think destroyStack is relevant. But if I use a
> stack as a data file, I want to read data, write data, and save the
> file. Am I missing something?
If you can read the stack file format you're a better programmer than I.
Raney advised against my early attempts at exploring it, for fear I'd
lose my sanity among the hashes. :)
As for custom formats, when you read a file do you expect it to remain
in memory by itself?
>> Ever make multi-user apps? I make quite a few.
> Come on, Richard! Stack files weren't made for multi-user access.
No file is "made for" multi-user accesses. But it happens that the
stack file format is enormously well suited for small data repositories,
given the ease with which we can get and set hierarchical data in
custom property sets.
Using stack files for data storage is a common approach. Given the
with-the-grain ease of doing so, I pity the productivity of anyone
storing small amounts of multi-part data in any other proprietary format.
> That's what databases are for.
Databases are for applications where the database becomes the governing
factor of most design decisions. Once you commit to using a database
you're stuck with the vendor's format, must make all gets and puts
through their APIs, and often this means multiple data files (I'm still
mystified why so many DB vendors can't put their metadata in a header of
the data file).
For small data sets you might be quite pleasantly surprised by how well
stack files can accomplish what you need in a simpler form.
> Of course we can use them, but we must
> expect to do a bit of work. In this case, either "delete stack" or
> "close stack" when you're finished with it, and whatever you do to
> indicate a file lock.
Of course. Or with my proposed change, no code is needed at all for
either desired circumstance: Just leave things alone to get what you're
looking for, or I can set a property to get what I'm looking for.
>> I'm not sure what "normal" means in this context. I think a lot of
>> single-user apps are "abnormal". :)
> You've been looking at my work again. :-)
I wish I've seen more. Whenever I prowl around in libURL my jaw drops
with the outstanding competency of what's written there, and when I use
it my appreciation grows even more for its ease and robustness.
Fourth World Media Corporation
Ambassador at FourthWorld.com http://www.FourthWorld.com
More information about the use-livecode