Thanks Pavel. Carolina will start to work with Ring2 and Calypso to work on micro kernels :)
Stef On Mon, Mar 26, 2018 at 11:41 AM, Pavel Krivanek <[email protected]> wrote: > Maybe, but it does not solve the issue because, in Ring, every model is a > full, closed and complete environment where every message tries to return > you reasonable value even for unresolved parts of the model. You can start > to build your model from everywhere you want. > > method := RGMethod named: #someMethod. > self assert: (method parent localMethods size = 1). > self assert: (method parent name = #unresolved). > self assert: (method parent package = method package). > > method parent name: #SomeBehavior. > self assert: method parent isTrait not. > method environment ensureTraitNamed: #SomeBehavior. > method package: (method environment ensurePackageNamed: > #PackageWithExtension). > self assert: method parent isTrait. > self assert: (method parent package ~~ method package). > > Cheers, > -- Pavel > > 2018-03-26 11:21 GMT+02:00 Guillermo Polito <[email protected]>: > >> Can't we make Extensions first class objects in ring? >> >> On Mon, Mar 26, 2018 at 11:02 AM, Pavel Krivanek < >> [email protected]> wrote: >> >>> 2018-03-26 10:52 GMT+02:00 Stephane Ducasse <[email protected]>: >>> > 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 >>> > <[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 >>> >> >>> > >>> >>> >> >> >> -- >> >> >> >> 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 <+33%206%2052%2070%2066%2013> >> > >
