Pavel's ChangeLog week of 2018-03-19
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
Pavel Why we do not know if this is a class or trait? May be we could have decided that Ring2 only works for new traits if this simplifies your life. Stef On Mon, Mar 26, 2018 at 10:37 AM, Pavel Krivanek <pavel.krivanek@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
2018-03-26 10:52 GMT+02:00 Stephane Ducasse <stepharo.self@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.krivanek@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
Can't we make Extensions first class objects in ring? On Mon, Mar 26, 2018 at 11:02 AM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
2018-03-26 10:52 GMT+02:00 Stephane Ducasse <stepharo.self@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.krivanek@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
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 <guillermopolito@gmail.com>:
Can't we make Extensions first class objects in ring?
On Mon, Mar 26, 2018 at 11:02 AM, Pavel Krivanek <pavel.krivanek@gmail.com
wrote:
2018-03-26 10:52 GMT+02:00 Stephane Ducasse <stepharo.self@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.krivanek@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 <+33%206%2052%2070%2066%2013>
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 <pavel.krivanek@gmail.com> 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 <guillermopolito@gmail.com>:
Can't we make Extensions first class objects in ring?
On Mon, Mar 26, 2018 at 11:02 AM, Pavel Krivanek < pavel.krivanek@gmail.com> wrote:
2018-03-26 10:52 GMT+02:00 Stephane Ducasse <stepharo.self@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.krivanek@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 <+33%206%2052%2070%2066%2013>
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 <pavel.krivanek@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
-- www.tudorgirba.com www.feenk.com "It's not how it is, it is how we see it."
Hi Pavel,
On Mar 26, 2018, at 10:37, Pavel Krivanek <pavel.krivanek@gmail.com <mailto:pavel.krivanek@gmail.com>> wrote:
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.
I am interested in playing with the recording-reproduce-and-revert feature. Is it possible? How do you compare it with Epicea? May your work replace Epicea (or part of it) or is it different? Cheers, Juraj
participants (5)
-
Guillermo Polito -
Juraj Kubelka -
Pavel Krivanek -
Stephane Ducasse -
Tudor Girba