Hi Andreas,<br> 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.<br> 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.
<br> 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.
<br><br> Thanks!<br> Hernan<br><br><br><div><span class="gmail_quote">On 9/6/07, <b class="gmail_sendername">Andreas Raab</b> <<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
How about, in addition to the traits refactorings, also looking at<br>alternative methods to achieve the same goals and compare and contrast<br>them? I find it unfortunate that so far no work has been done that<br>actually compares refactorings with traits to those done without and see
<br>what the differences and similarities are.<br><br>Cheers,<br> - Andreas<br><br>mrgonza78 wrote:<br>> In my particular case, what I'm doing is a master thesis about trait aware<br>> refactorings. I'm not looking for the best usages of traits. My focus is on
<br>> the traits aware refactorings I'm working on.<br>> That's on one hand, on the other hand I agree that just removing code<br>> duplicated across hierarchies is not the best way of selling traits.<br>
> I posted the message because I don't only want to show the result of the<br>> refactorings per se, but I also look for a good case in which traits fits<br>> well (if the effort of the refactoring doesn't get me out of my thesis).
<br>> I think what I'll end doing is half and a half: I'll apply refactorings just<br>> to remove duplicated code or just for the sake of the refactorings (so I can<br>> collect result or conclusions from them) and also, I'll aply refactorings
<br>> for the sake of both the refactorings and traits (so I can collect result or<br>> conclusions from the refactorings and at the same time show how good traits<br>> are).<br>> May be I was too ambitious when I named Seaside, Magritte and Morph. Looking
<br>> for good traits and refactoring in those framework may take me several<br>> months and may be subject of it's own thesis (if any).<br>> Thanks for the mind set and hints, I found them very useful.<br>> Alejandro
<br>><br>><br>> Jason Johnson-5 wrote:<br>>> Keep in mind that Traits are not at the same level as inheritance, for<br>>> instance. I wouldn't think of traits as a means of eliminating code<br>>> duplication, even if that is how they are often sold. I would try to
<br>>> keep the mind set that Traits are.... traits. That is "am I working<br>>> here with a new entity? (create a class) An entity that has various<br>>> specializations? (create subclasses) Or am I working with a trait that
<br>>> many unrelated classes have? (trait)".<br>>><br>>> If you use this mindset then I think you can find elegant places for<br>>> traits when they are needed. If we go around looking for duplicated
<br>>> code and stick a trait in there we will end up with a mess. There are<br>>> many ways of eliminating duplicate code, you don't need traits for<br>>> this.<br>>><br>>> Having said that, I would like to see what you've done with Magnitude
<br>>> as that is a very obvious trait in my opinion. To find a trait look<br>>> for classes that seem to be inherited to the wrong place, purely to<br>>> gain some interface or something. A trait could be hiding there, or
<br>>> it could simply be a case that needs normal traditional refactoring.<br>>><br>>> The other thing I would personally keep in mind is that traits<br>>> probably work best when kept small. For example, in Magnitude you
<br>>> basically just have equality and comparison. I would even break that<br>>> up to an equality trait (for things which can be equal) and a<br>>> comparison trait (for things which can be compared). If you get a
<br>>> trait that is as big as a class, then I would consider that a strong<br>>> code smell.<br>>><br>>> On 9/6/07, Alejandro Gonzalez <<a href="mailto:mrgonza78@gmail.com">mrgonza78@gmail.com</a>
> wrote:<br>>>> Hi,<br>>>> I'm working in trait aware refactorings, and I reached a point in which<br>>>> I<br>>>> have to use them so as to give them a try in real cases and see how
<br>>>> suitable<br>>>> they are or see what other features should be nice to have.<br>>>> I'm wandering through the image looking for good candidates to apply<br>>>> traits. I started (and I already finished) with Magnitude and a few
<br>>>> particular classes. Now it's time for another refactoring a little more<br>>>> ambitious, but not many ideas have came out of my mind so far :(<br>>>> Stream and Collection (I know the latter was already refactored) are
<br>>>> good<br>>>> candidates, I'll start looking at them, but I was wondering if there<br>>>> wasn't<br>>>> other projects/frameworks like Seaside, Magritte, Morph? or something
<br>>>> else,<br>>>> that could benefit from traits.<br>>>> I'm not looking to implement something with traits from scratch, I just<br>>>> want to take a set of classes, methods (or traits, why not) and
<br>>>> restructure<br>>>> code by applying refactorings instead of doing it manually.<br>>>> Anyone having an idea, please let me know it. Just name a class and a<br>>>> couple of methods you know are spread across several classes and where
<br>>>> you<br>>>> think traits would help, and I'll figure out what and how to refactor.<br>>>> Thanks in advance<br>>>> Alejandro<br>>>><br>>>><br>>>>
<br>>>><br>>><br>>><br>><br><br><br></blockquote></div><br>