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
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 <pavel.krivanek@gmail.com> 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
2017-06-27 14:26 GMT+02:00 Juraj Kubelka <juraj.kubelka@icloud.com>:
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 <pavel.krivanek@gmail.com> 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
El 27-06-2017, a las 14:43, Pavel Krivanek <pavel.krivanek@gmail.com> escribió:
2017-06-27 14:26 GMT+02:00 Juraj Kubelka <juraj.kubelka@icloud.com <mailto:juraj.kubelka@icloud.com>>: 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 <pavel.krivanek@gmail.com <mailto:pavel.krivanek@gmail.com>> 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
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 <juraj.kubelka@icloud.com> wrote:
El 27-06-2017, a las 14:43, Pavel Krivanek <pavel.krivanek@gmail.com> escribió:
2017-06-27 14:26 GMT+02:00 Juraj Kubelka <juraj.kubelka@icloud.com>:
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 <pavel.krivanek@gmail.com> 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* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
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 <guillermopolito@gmail.com>:
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 <juraj.kubelka@icloud.com> wrote:
El 27-06-2017, a las 14:43, Pavel Krivanek <pavel.krivanek@gmail.com> escribió:
2017-06-27 14:26 GMT+02:00 Juraj Kubelka <juraj.kubelka@icloud.com>:
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 <pavel.krivanek@gmail.com> 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* <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>
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
2017-06-27 14:27 GMT+02:00 Peter Uhnak <i.uhnak@gmail.com>:
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
participants (4)
-
Guillermo Polito -
Juraj Kubelka -
Pavel Krivanek -
Peter Uhnak