> El 27-06-2017, a las 14:43, Pavel Krivanek <[email protected]> > escribió: > > > > 2017-06-27 14:26 GMT+02:00 Juraj Kubelka <[email protected] > <mailto:[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.
That’s interesting. Thanks for the explanation :-) Juraj > > -- Pavel > > > > Cheers, > Juraj > > > El 27-06-2017, a las 14:16, Pavel Krivanek <[email protected] > > <mailto:[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 > > >
