Hi, I did some serious Ring 2 refactorings that I wanted to have finished before the integration into Pharo. Because Pharo now starts to support the stateful traits, it needs to be supported by the metamodel too. However, we need to be able to model the images with the old traits as well and from the internal point of view, they are quite different. Moreover, if you load a code into the Ring model, you sometimes do not know if the behavior, where you load a method, is a class or you later will realize that it is a trait. The Ring 2 used for this a complex machinery that was able to switch the behavior kind using the #becomeForward: message. Some time ago I decided to solve both problems by introducing of the behavior strategies. That means that every behavior is a composition of an instance of the RGBehavior class and a behavior strategy (e.g. RGClassStrategy). Then changing of the behavior kind is then only a matter of swapping of the strategy (which has a state so it not so straightforward but still easy). The classes like RGClass or RGTrait are still present but now they are only the factories that produce the behaviors and they have no real instances.
The next big thing I decided to do in Ring is renaming of the entities. From the beginning, I used the prefix "RG2" to avoid the collisions with the old Ring implementation but I supposed that before the final release it will be renamed because, from the user perspective, the Ring 2 should be a replacement for the old Ring and not completely separate project. The attempts to replace the old Ring with the new one showed me, that it is possible, but the old Ring is so deeply used in the system that it leads to a huge amount of instabilities. So I decided to rename the Ring 2 classes and some methods to do not make collisions with the old implementation. While the old Ring class was named RGClassDefinition and in Ring 2 it was RG2ClassDefinition, now it is renamed simply to RGClass. RG2Definition was renamed to RGObject. The only ugly exception is RG2Package which is now named RGPackageDefinition because the old Ring does not follow the naming convention and uses the name "RGPackage". The old Ring packages will get suffix "Deprecated" into their names. The old Ring and the Ring2 can coexist in one image and it is still possible to load the new Ring into the Pharo 6. Then I started to work on the changes metamodel for Ring with the goal to be able to record, reproduce and revert (almost) all changes that the user does in the model. The main goal of it is to be able to get comparisons of two models and compute loading order of the changes so it will be more easy to replace the Monticello metamodel and the metamodel for code differences with a single solid solution based on Ring. Cheers, -- Pavel
