Hi--

I've just started following up on an idea I mentioned a while ago, a mechanism for storing and restoring past versions of methods and classes. It effectively replaces the traditional changes and sources files, and is used by the module system to perform module unloading.

When a system wants to store a method or class (for example, when it is about to overwrite an old method with a newly-compiled version), it makes a request via remote message to an entirely separate object memory dedicated to archival (which may also perform archival for any number of other systems). Methods, classes, and metadata about them (such as author and source code) are stored as objects. The archival system snapshots itself after every addition (not a big deal since it's relatively small). I think having a real system available to help with version browsing and crash recovery, as opposed to a text file, will be a lot more powerful.

Modules use the archival system during loading to keep track of the components they happen to replace (old methods and classes). Each module creates an "antimodule" which, when installed, reverts the system to the way it was before installing the module, drawing upon the old components stored in the archive. Note that the antimodule for a given module varies depending on the state of the system into which it is installed. This seems to highlight the advantage of using live negotiating objects to convey behavior, rather than static files.

As always, I very much welcome questions and feedback!

The Spoon project website is http://netjam.org/spoon/.

thanks,

-C