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
___________________________________________________________
[EMAIL PROTECTED] http://www.FourthWorld.com
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
