Live Class Evolution in Magma
Last updated at 4:24 pm UTC on 22 December 2005
Overview
Magma and Monticello can serve as a basis for a distributed team of developers in different geographic locations to collaborate on both the objects and code of a domain model. Developers may remain connected to the repository during development, as class evolution occurs, and Magma will try to "do the right thing" within the scope of each connected image.
Principles
Distributed development via Magma is based on the following principles:
- With one exception, no code is ever installed or modified automatically by Magma. Only the developer knows what code he or she wants at any particular time and they must explicitly load code from Magma.
- No code is ever committed automatically by Magma. Only the developer knows what code should be committed, and they must explicitly commit code to the repository.
- No developer shall be required to disconnect from the repository while developing code and classes. Magma should not blow up just because your shape of ClassX does not match another shape of a materializing instance of ClassX.*
[*] The one exception is if the class-type changes; e.g., Pointers vs Bytes vs Words. This is not supported.
Class Evolution
As distributed developers connected to the same repository commit instances, Magma will map the variables by name. Classes may be renamed and Magma will detect the existing instances are instances of the newly named class, even in your co-developers images who haven't renamed that class.
Instance-variable renames are not tracked; for now you have to deal with this manually.
If Developer1 adds a variable and commits an instance, Developer2 may still read that object, but if they have not added the same variable they obviously won't have the newly committed object in that new slot. If they then try to commit a change to that object they will get a MagmaTruncationWarning informing them they are about to truncate data.
Implementation
Magma keeps a collection of MaClassDefinitions, an object which describes the particular state of a class at a particular time, in its repository definition.
When an object is read, Magma will map the instance-variables by name to whatever class has the same name. This is the way Smalltalk has always handled this. If a class with that name doesn't exist in the image, it compiles one according to the MaClassDefinition for that object.
Magma does keep track when classes are renamed. If a class is renamed, Magma will know to map old instances to the newly named class.
Currently, renaming an instance variable is seen as a new variable and not automatically transferred.
Upgrade strategies
There are a number of strategies for "upgrading" old-version objects to a newer version.
- lazy-initialization of new variables
- one-shot script to enumerate all instances and populate
- a faster one-shot script that operates directly on the MaObjectBuffers using MagmaFileTraverser