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
--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]
_______________________________________________
Spoon mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon
Locked
