Live Class Evolution in Magma
Last updated at 3:57 pm UTC on 19 June 2013
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.
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.
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 an instance variable and commits references to it, other developers may still read that object, but if the version of the same class in their image does not have the newly-added variable, any commits they do to that object may cause that variable to be reset back to nil. Typically, new variables are only added in "development" where coordination with other developers is common anyway.
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.
As in any database, two common strategies for "upgrading" old-version objects to a newer version are:
- lazy-initialization of new variables
- a one-shot script to enumerate all instances and populate