Can't we make Extensions first class objects in ring? On Mon, Mar 26, 2018 at 11:02 AM, Pavel Krivanek <pavel.kriva...@gmail.com> wrote:
> 2018-03-26 10:52 GMT+02:00 Stephane Ducasse <stepharo.s...@gmail.com>: > > Pavel > > > > Why we do not know if this is a class or trait? > > Imagine that you are loading a package that has an extension method to > a class in a foreign package. It is identified only by the behavior > name, e.g. "TBehavior". But later, e.g. during merging of the package > model with some other, you will realize that the method is in fact a > part of a trait so you need to change kind of the class stub you > already have. > > > Maybe we could have decided that Ring2 only works for new traits if > > this simplifies your life. > > Because the traits are now a library and anyone can come with its own > metaclass that modifies the behavior metamodel, it is reasonable to > support it. And anyway, this work is already done ;-) > > -- Pavel > > > Stef > > > > On Mon, Mar 26, 2018 at 10:37 AM, Pavel Krivanek > > <pavel.kriva...@gmail.com> 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 > >> > > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
