Smalltalk › Pharo › Pharo Smalltalk Developers

Flattened traits in Pharo 7

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

Pavel Krivanek-3

Flattened traits in Pharo 7

Hi,

because we want to have traits only as an option where people will be able to choose custom traits implementation, the Pharo kernel cannot depend on them. For that reason we had to flatten all classes that use traits in the kernel packages.

That means that methods from system traits as TBehavior [1] were copied to the trait users and the traits were removed from the class definitions. For now these traits are still present in the image.

If you use own traits in your projects, this step will have no impact on you. Only if your project extends the system traits, you will need to adopt it for Pharo 7.

[1] complete list: TApplyingOnClassSide TBehavior TBehaviorCategorization TClass TClassDescription TComposingDescription TSortable TTranscript TTransformationCompatibility

Cheers,

-- Pavel

Juraj Kubelka

Re: Flattened traits in Pharo 7

Just for curiosity: Is it a good decision? It is supposed that with Traits we can have less code duplication. And maybe the code duplication happens also in the Pharo kernel, right?

Thanks for any explanation :-)

Cheers,
Juraj

> El 27-06-2017, a las 14:16, Pavel Krivanek <[hidden email]> escribió:
>
> Hi,
>
> because we want to have traits only as an option where people will be able to choose custom traits implementation, the Pharo kernel cannot depend on them. For that reason we had to flatten all classes that use traits in the kernel packages.
> That means that methods from system traits as TBehavior [1] were copied to the trait users and the traits were removed from the class definitions. For now these traits are still present in the image.
> If you use own traits in your projects, this step will have no impact on you. Only if your project extends the system traits, you will need to adopt it for Pharo 7.
>
> [1] complete list: TApplyingOnClassSide TBehavior TBehaviorCategorization TClass TClassDescription TComposingDescription TSortable TTranscript TTransformationCompatibility
>
> Cheers,
> -- Pavel

Peter Uhnak

Re: Flattened traits in Pharo 7

In reply to this post by Pavel Krivanek-3

Just so I understand... if I have extended e.g. TBehavior, I will need to lookup all the users and copy the method everywhere?

On Tue, Jun 27, 2017 at 02:16:14PM +0200, Pavel Krivanek wrote:

> Hi,
>
> because we want to have traits only as an option where people will be able
> to choose custom traits implementation, the Pharo kernel cannot depend on
> them. For that reason we had to flatten all classes that use traits in the
> kernel packages.
> That means that methods from system traits as TBehavior [1] were copied to
> the trait users and the traits were removed from the class definitions. For
> now these traits are still present in the image.
> If you use own traits in your projects, this step will have no impact on
> you. Only if your project extends the system traits, you will need to adopt
> it for Pharo 7.
>
> [1] complete list: TApplyingOnClassSide TBehavior TBehaviorCategorization
> TClass TClassDescription TComposingDescription TSortable TTranscript
> TTransformationCompatibility
>
> Cheers,
> -- Pavel

Pavel Krivanek-3

Re: Flattened traits in Pharo 7

2017-06-27 14:27 GMT+02:00 Peter Uhnak <[hidden email]>:

Just so I understand... if I have extended e.g. TBehavior, I will need to lookup all the users and copy the method everywhere?

Yes

-- Pavel

On Tue, Jun 27, 2017 at 02:16:14PM +0200, Pavel Krivanek wrote:
> Hi,
>
> because we want to have traits only as an option where people will be able
> to choose custom traits implementation, the Pharo kernel cannot depend on
> them. For that reason we had to flatten all classes that use traits in the
> kernel packages.
> That means that methods from system traits as TBehavior [1] were copied to
> the trait users and the traits were removed from the class definitions. For
> now these traits are still present in the image.
> If you use own traits in your projects, this step will have no impact on
> you. Only if your project extends the system traits, you will need to adopt
> it for Pharo 7.
>
> [1] complete list: TApplyingOnClassSide TBehavior TBehaviorCategorization
> TClass TClassDescription TComposingDescription TSortable TTranscript
> TTransformationCompatibility
>
> Cheers,
> -- Pavel

Pavel Krivanek-3

Re: Flattened traits in Pharo 7

In reply to this post by Juraj Kubelka

2017-06-27 14:26 GMT+02:00 Juraj Kubelka <[hidden email]>:

Just for curiosity: Is it a good decision? It is supposed that with Traits we can have less code duplication. And maybe the code duplication happens also in the Pharo kernel, right?

Thanks for any explanation :-)

You are right, it will cause more code duplicities in the kernel. On the other hand we will be able to clean the traits implementation and make it more modular, so the users will have more options like stateful traits, talents etc. We needed to do a small step back to be able to move forward.

It was not an easy decision but it was planned for a long time. And in the end, this decision was done by people who introduced traits and invested a lot of time and effort into them.

-- Pavel

Cheers,
Juraj

> El 27-06-2017, a las 14:16, Pavel Krivanek <[hidden email]> escribió:
>
> Hi,
>
> because we want to have traits only as an option where people will be able to choose custom traits implementation, the Pharo kernel cannot depend on them. For that reason we had to flatten all classes that use traits in the kernel packages.
> That means that methods from system traits as TBehavior [1] were copied to the trait users and the traits were removed from the class definitions. For now these traits are still present in the image.
> If you use own traits in your projects, this step will have no impact on you. Only if your project extends the system traits, you will need to adopt it for Pharo 7.
>
> [1] complete list: TApplyingOnClassSide TBehavior TBehaviorCategorization TClass TClassDescription TComposingDescription TSortable TTranscript TTransformationCompatibility
>
> Cheers,
> -- Pavel

Juraj Kubelka

Re: Flattened traits in Pharo 7

El 27-06-2017, a las 14:43, Pavel Krivanek <[hidden email]> escribió:

2017-06-27 14:26 GMT+02:00 Juraj Kubelka <[hidden email]>:
Just for curiosity: Is it a good decision? It is supposed that with Traits we can have less code duplication. And maybe the code duplication happens also in the Pharo kernel, right?

Thanks for any explanation :-)

You are right, it will cause more code duplicities in the kernel. On the other hand we will be able to clean the traits implementation and make it more modular, so the users will have more options like stateful traits, talents etc. We needed to do a small step back to be able to move forward.
It was not an easy decision but it was planned for a long time. And in the end, this decision was done by people who introduced traits and invested a lot of time and effort into them.

That’s interesting. Thanks for the explanation :-)

Juraj

-- Pavel

Cheers,
Juraj

> El 27-06-2017, a las 14:16, Pavel Krivanek <[hidden email]> escribió:
>
> Hi,
>
> because we want to have traits only as an option where people will be able to choose custom traits implementation, the Pharo kernel cannot depend on them. For that reason we had to flatten all classes that use traits in the kernel packages.
> That means that methods from system traits as TBehavior [1] were copied to the trait users and the traits were removed from the class definitions. For now these traits are still present in the image.
> If you use own traits in your projects, this step will have no impact on you. Only if your project extends the system traits, you will need to adopt it for Pharo 7.
>
> [1] complete list: TApplyingOnClassSide TBehavior TBehaviorCategorization TClass TClassDescription TComposingDescription TSortable TTranscript TTransformationCompatibility
>
> Cheers,
> -- Pavel

Guillermo Polito

Re: Flattened traits in Pharo 7

But that's not the case. The only usage of traits in the Kernel is TBehaviour, to share some common behaviour between traits and classes. But Pablo is working on a new modular implementation of traits that would not require TBehavior, and would simplify the code of classes.

On Tue, Jun 27, 2017 at 3:04 PM, Juraj Kubelka <[hidden email]> wrote:

El 27-06-2017, a las 14:43, Pavel Krivanek <[hidden email]> escribió:

2017-06-27 14:26 GMT+02:00 Juraj Kubelka <[hidden email]>:
Just for curiosity: Is it a good decision? It is supposed that with Traits we can have less code duplication. And maybe the code duplication happens also in the Pharo kernel, right?

Thanks for any explanation :-)

You are right, it will cause more code duplicities in the kernel. On the other hand we will be able to clean the traits implementation and make it more modular, so the users will have more options like stateful traits, talents etc. We needed to do a small step back to be able to move forward.
It was not an easy decision but it was planned for a long time. And in the end, this decision was done by people who introduced traits and invested a lot of time and effort into them.

That’s interesting. Thanks for the explanation :-)

Juraj

-- Pavel

Cheers,
Juraj

> El 27-06-2017, a las 14:16, Pavel Krivanek <[hidden email]> escribió:
>
> Hi,
>
> because we want to have traits only as an option where people will be able to choose custom traits implementation, the Pharo kernel cannot depend on them. For that reason we had to flatten all classes that use traits in the kernel packages.
> That means that methods from system traits as TBehavior [1] were copied to the trait users and the traits were removed from the class definitions. For now these traits are still present in the image.
> If you use own traits in your projects, this step will have no impact on you. Only if your project extends the system traits, you will need to adopt it for Pharo 7.
>
> [1] complete list: TApplyingOnClassSide TBehavior TBehaviorCategorization TClass TClassDescription TComposingDescription TSortable TTranscript TTransformationCompatibility
>
> Cheers,
> -- Pavel

Guille Polito

Research Engineer

French National Center for Scientific Research - http://www.cnrs.fr

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Pavel Krivanek-3

Re: Flattened traits in Pharo 7

Besides several TBehavior-like traits with more than one user in the kernel (TApplyingOnClassSide TBehavior TClass TClassDescription TComposingDescription) we have some more general ones (TSortable TTranscript). So we will have some code duplicities.

-- Pavel

2017-06-27 15:13 GMT+02:00 Guillermo Polito <[hidden email]>:

But that's not the case. The only usage of traits in the Kernel is TBehaviour, to share some common behaviour between traits and classes. But Pablo is working on a new modular implementation of traits that would not require TBehavior, and would simplify the code of classes.

On Tue, Jun 27, 2017 at 3:04 PM, Juraj Kubelka <[hidden email]> wrote:

El 27-06-2017, a las 14:43, Pavel Krivanek <[hidden email]> escribió:

2017-06-27 14:26 GMT+02:00 Juraj Kubelka <[hidden email]>:
Just for curiosity: Is it a good decision? It is supposed that with Traits we can have less code duplication. And maybe the code duplication happens also in the Pharo kernel, right?

Thanks for any explanation :-)

You are right, it will cause more code duplicities in the kernel. On the other hand we will be able to clean the traits implementation and make it more modular, so the users will have more options like stateful traits, talents etc. We needed to do a small step back to be able to move forward.
It was not an easy decision but it was planned for a long time. And in the end, this decision was done by people who introduced traits and invested a lot of time and effort into them.

That’s interesting. Thanks for the explanation :-)

Juraj

-- Pavel

Cheers,
Juraj

> El 27-06-2017, a las 14:16, Pavel Krivanek <[hidden email]> escribió:
>
> Hi,
>
> because we want to have traits only as an option where people will be able to choose custom traits implementation, the Pharo kernel cannot depend on them. For that reason we had to flatten all classes that use traits in the kernel packages.
> That means that methods from system traits as TBehavior [1] were copied to the trait users and the traits were removed from the class definitions. For now these traits are still present in the image.
> If you use own traits in your projects, this step will have no impact on you. Only if your project extends the system traits, you will need to adopt it for Pharo 7.
>
> [1] complete list: TApplyingOnClassSide TBehavior TBehaviorCategorization TClass TClassDescription TComposingDescription TSortable TTranscript TTransformationCompatibility
>
> Cheers,
> -- Pavel

--

Guille Polito

Research Engineer

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