Traits or not Traits that is the question

Alain Plantec alain.plantec at univ-brest.fr
Sun Feb 3 21:50:10 UTC 2008


On Sunday 03 February 2008 20:47, Michael van der Gulik wrote:
> On Feb 4, 2008 1:59 AM, Igor Stasenko <siguctua at gmail.com> wrote:
> > Recently, there are voices from many sides, saying that Traits is
> > show-stopper and should be retained from future squeak versions.
> > I'd like to hear an arguments of both sides.
> >
> > Personally, what i think, Traits have good potential, but sadly there
> > is lack of support of them in current dev tools, what in own turn,
> > returns us to discussion about improving dev tools to meet
> > requirements :)
>
> Could anybody who is actually *using* traits please raise their hand?
me!
It's especially a very interesting tool when you are refactoring (but not 
only).

Three things:
-One of the very important things while refactoring is to detect and reduce 
code duplication. Traits are then very useful because you can efficiently try 
new code distribution without changing your classes organization.
I can understand that people are not using traits while implementing new  
developments. Maybe it's because class thinking is then much more important.
Maybe it's because people simply don't try to use traits. Maybe it's because 
traits are young.

But, after a while, when you have numerous users, when a lot of clients are 
using your component it is very difficult to reorganize your own classes in 
order to reduce code duplication. Is'nt it one of the big difficulty of 
squeak image refactoring ? 

-Maybe a new design without traits is better than a new design with traits. 
But it has a cost. Less good design are very often preferred because of money 
and time limitation. I think here traits can be very useful again by avoiding 
code duplication at less cost than with a pure OO design and with much more 
better style than with simple code duplication. 

-Another advantage of traits is two clearly indicate WHERE you have code 
duplication and WHICH classes could be concerned by a deep refactoring.  
Who have a clear view of code duplication in basic standard squeak image?
Does it makes no sense to think that a good step for squeak image refactoring  
could be to reduce all code duplication with traits. A second step could be 
traits refactoring and removing by class re-organization or new classes 
introduction. But I'm not sure that all of them will be removed.

alain
 
> Gulik.



More information about the Squeak-dev mailing list