Rules governing stack purging

[Richard Gaskin]

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 
disposed of.

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 
unnecessarily frightening).

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  
>> setting?
> 
> 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.

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com