Pavel's ChangeLog week of 2018-03-19

2018-03-26 10:52 GMT+02:00 Stephane Ducasse <[hidden email]>:
> 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
> <[hidden email]> 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 <[hidden email]> wrote:

2018-03-26 10:52 GMT+02:00 Stephane Ducasse <[hidden email]>:
> 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
> <[hidden email]> 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 Web: http://guillep.github.io Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+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 <[hidden email]>:

Can't we make Extensions first class objects in ring?

On Mon, Mar 26, 2018 at 11:02 AM, Pavel Krivanek <[hidden email]> wrote:

2018-03-26 10:52 GMT+02:00 Stephane Ducasse <[hidden email]>:
> 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
> <[hidden email]> 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 Web: http://guillep.github.io Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13