This sounds really exciting! I’d be very curious to learn more about this.
Cheers, Doru > On Mar 26, 2018, at 10:37 AM, Pavel Krivanek <[email protected]> wrote: > > 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 > -- www.tudorgirba.com www.feenk.com "It's not how it is, it is how we see it."
