Ideas for a refactoring with traits?

How about, in addition to the traits refactorings, also looking at
alternative methods to achieve the same goals and compare and contrast
them? I find it unfortunate that so far no work has been done that
actually compares refactorings with traits to those done without and see
what the differences and similarities are.

Cheers,
   - Andreas

mrgonza78 wrote:
> In my particular case, what I'm doing is a master thesis about trait aware
> refactorings. I'm not looking for the best usages of traits. My focus is on
> the traits aware refactorings I'm working on.
> That's on one hand, on the other hand I agree that just removing code
> duplicated across hierarchies is not the best way of selling traits.
> I posted the message because I don't only want to show the result of the

> refactorings per se, but I also look for a good case in which traits fits
> well (if the effort of the refactoring doesn't get me out of my thesis).
> I think what I'll end doing is half and a half: I'll apply refactorings just
> to remove duplicated code or just for the sake of the refactorings (so I can
> collect result or conclusions from them) and also, I'll aply refactorings
> for the sake of both the refactorings and traits (so I can collect result or
> conclusions from the refactorings and at the same time show how good traits
> are).
> May be I was too ambitious when I named Seaside, Magritte and Morph. Looking
> for good traits and refactoring in those framework may take me several
> months and may be subject of it's own thesis (if any).
> Thanks for the mind set and hints, I found them very useful.
> Alejandro
>
>
> Jason Johnson-5 wrote:
>> Keep in mind that Traits are not at the same level as inheritance, for
>> instance.  I wouldn't think of traits as a means of eliminating code
>> duplication, even if that is how they are often sold.  I would try to
>> keep the mind set that Traits are.... traits.  That is "am I working
>> here with a new entity? (create a class) An entity that has various
>> specializations? (create subclasses) Or am I working with a trait that
>> many unrelated classes have? (trait)".
>>
>> If you use this mindset then I think you can find elegant places for
>> traits when they are needed.  If we go around looking for duplicated
>> code and stick a trait in there we will end up with a mess.  There are
>> many ways of eliminating duplicate code, you don't need traits for
>> this.
>>
>> Having said that, I would like to see what you've done with Magnitude
>> as that is a very obvious trait in my opinion.  To find a trait look
>> for classes that seem to be inherited to the wrong place, purely to
>> gain some interface or something.  A trait could be hiding there, or
>> it could simply be a case that needs normal traditional refactoring.
>>
>> The other thing I would personally keep in mind is that traits
>> probably work best when kept small.  For example, in Magnitude you
>> basically just have equality and comparison.  I would even break that
>> up to an equality trait (for things which can be equal) and a
>> comparison trait (for things which can be compared).  If you get a
>> trait that is as big as a class, then I would consider that a strong
>> code smell.
>>
>> On 9/6/07, Alejandro Gonzalez <[hidden email] > wrote:
>>> Hi,
>>>   I'm working in trait aware refactorings, and I reached a point in which
>>> I
>>> have to use them so as to give them a try in real cases and see how
>>> suitable
>>> they are or see what other features should be nice to have.
>>>   I'm wandering through the image looking for good candidates to apply
>>> traits. I started (and I already finished)  with Magnitude and a few
>>> particular classes. Now it's time for another refactoring a little more
>>> ambitious, but not many ideas have came out of my mind so far :(
>>>   Stream and Collection (I know the latter was already refactored) are
>>> good
>>> candidates, I'll start looking at them, but I was wondering if there
>>> wasn't
>>> other projects/frameworks like Seaside, Magritte, Morph? or something
>>> else,
>>> that could benefit from traits.
>>>   I'm not looking to implement something with traits from scratch, I just
>>> want to take a set of classes, methods (or traits, why not) and
>>> restructure
>>> code by applying refactorings instead of doing it manually.
>>>    Anyone having an idea, please let me know it. Just name a class and a
>>> couple of methods you know are spread across several classes and where
>>> you
>>> think traits would help, and I'll figure out what and how to refactor.
>>>   Thanks in advance
>>>   Alejandro
>>>
>>>
>>>
>>>
>>
>>
>

Hernan Wilkinson wrote:
> Hi Andreas,
>  there are other guys (Claudio and Nicolas, they just sent and email
> about traits browser) that are doing something quite similar to what you
> suggest.
>  They will re-implement the Collection hierarchy using traits and
> compare that model to the current Collection hierarchy to see if they
> got a better model/implementation using traits or not.

But this isn't a particularly valid comparison. If you want to find out
about the value of traits you can't compare a subsystem that is being
used in production and that has all kinds of legacy issues with one that
doesn't have to deal with such issues. What you are comparing then is:
Is a subsystem which can be implemented free of constraints superior to
one that has to accommodate all sorts of constraints and legacy issues?
I can tell you the answer to that question without running the
experiment. And it has nothing to do with traits.

So either you need to run the experiment within the same constraints
that exist already (in which case you should do an in situ
reimplementation of the collection hierarchy with the requirement of
keeping the system running while doing it) or you need to implement both
parts free of the constraints of the current system. Which are both fine
options btw.

> I think that doing exactly what you suggest in this case is not easy
> because there is a well accepted implementation of the Collection
> hierarchy... we should look for another problem to apply your idea
> without "noise"... I keep that in mind and offer your idea to other
> students.

I think it is *very* easy to do what I proposed as long as you are clear
what your goals for the refactorings are other than "use traits". If
your goal is, for example, "minimize code duplication" it's clear how to
do this without traits. If it is "minimize number of entities", it's
clear, too. So is "restructure into more useful/generalized entities" or
"unify the interfaces". As long as you are clear on what goals you're
actually trying to achieve it's pretty clear how to achieve these goals
with or without traits.

Cheers,
   - Andreas