Hi Igor--
Every time the subject memory adds, changes, or removes a class definition, method, author, comment, tag, or module, or makes a checkpoint (i.e., makes an edit), it adds the appropriate editions to the history memory via remote messages. The history memory snapshots itself after every edit, so as to provide crash recovery support.
Hmm, this could be a bit heavyweight. A history can grow to multiple hundreds of megabytes, then, imagine how slow it could be when you have to snapshot full image at every change.
As optimization, it could use a temporary file(s) to save incremental changes, to avoid snapshotting at each edit. Then it can do full snapshots when incremental file grows bigger than certain amount or by direct request to clean-out incremental storage.
Well, these days even memories that large have snapshot times that fall within the idle intervals of a development system. But assuming it's a problem, I'd rather divide the history memory into several memories (probably by how utilized the editions are). I can also imagine limited periods where one is willing to forego edition-by-edition crash recovery (e.g., when installing a set of changes which are meant to be atomic). The subject could keep track of the change order and report it to the history memory later, if desired.
Since there is no single, global SystemDictionary its pointless to discuss the cos and pros of namespaces. In your system each class/module effectively is name space, the question, of course, how to reflect the new capabilities of system in a way which don't shatter the [foundation] of smalltalk syntax and its spirit.
Well, my proposal doesn't change the syntax at all, although it does impose additional responsibilities on the tools. Since the existence of a single system dictionary was always an implementation detail and never part of the fundamental spirit of the system, I think we're okay there, too.
thanks!
-C
-- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]
spoon@lists.squeakfoundation.org