2017-06-27 14:26 GMT+02:00 Juraj Kubelka <[email protected]>: > 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 <[email protected]> > 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 > > >
