Hi Andreas,<br>&nbsp;thank you for your comments. I agree with you in most of them. It may not be a good comparison although we are going to re implement the collection hierarchy first and the refactor it with traits.<br>&nbsp;At the same time it will allow us to gain experience with traits and &quot;measure&quot; if it is a good tool or not.
<br>&nbsp;Here is a copy of the process we will follow (I sent it in other mail):<br><br>&gt; 1) Take a concrete class of the Collection hierarchy, for example OrderedCollection<br>&gt; 2) Create a new class (ie. XOrderedCollection) with Object as super class
<br>&gt; 3) Take a message of the ANSI Smalltalk of the selected class (OrderedCollection)<br>&gt; 4) Write a test, make it work with the selected class (OrderedCollection)<br>&gt; 5) Make the test written in 4) work with the class created in steep 2. ( XOrderedCollection)
<br>&gt; 6) Repeat 3,4 and 5 until all messages of the selected class
(OrderedCollection) are implemented in the other class
(XOrderedCollection)<br>&gt; 7) Select another concrete class from the Collection hierarchy (for example Array) and repeat steps from 2 to 6.
<br>&gt; 8) Repeat steep 7 until there are enough new implementations to infer traits. <br>&gt; 9) Refactor the new classes into traits... and play with the model until we feel comfortable with the result.<br>&gt;<br>&gt; To
put a limit in the project, they are going to implement just the ANSI
Collection hierarchy &gt;(remember that it is a master thesis...)
<br>
&gt;<br>&gt; We thought that doing it this way the new implementation is not
going to be &quot;guided&quot; by the &gt;old one, we will just keep the concrete
classes names but not the hierarchy necessarily...<br>&gt;<br>&gt; Please, feel free to let us know what you thing about this process, if you have other ideas, &gt;etc.
<br><br>Bye,<br>Hernan.<br><br><div><span class="gmail_quote">On 9/6/07, <b class="gmail_sendername">Andreas Raab</b> &lt;<a href="mailto:andreas.raab@gmx.de" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
andreas.raab@gmx.de
</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hernan Wilkinson wrote:<br>&gt; Hi Andreas,<br>&gt;&nbsp;&nbsp;there are other guys (Claudio and Nicolas, they just sent and email
<br>&gt; about traits browser) that are doing something quite similar to what you<br>&gt; suggest.<br>&gt;&nbsp;&nbsp;They will re-implement the Collection hierarchy using traits and<br>&gt; compare that model to the current Collection hierarchy to see if they
<br>&gt; got a better model/implementation using traits or not.<br><br>But this isn&#39;t a particularly valid comparison. If you want to find out<br>about the value of traits you can&#39;t compare a subsystem that is being
<br>used in production and that has all kinds of legacy issues with one that<br>doesn&#39;t have to deal with such issues. What you are comparing then is:<br>Is a subsystem which can be implemented free of constraints superior to
<br>one that has to accommodate all sorts of constraints and legacy issues?<br>I can tell you the answer to that question without running the<br>experiment. And it has nothing to do with traits.<br><br>So either you need to run the experiment within the same constraints
<br>that exist already (in which case you should do an in situ<br>reimplementation of the collection hierarchy with the requirement of<br>keeping the system running while doing it) or you need to implement both<br>parts free of the constraints of the current system. Which are both fine
<br>options btw.<br><br>&gt; I think that doing exactly what you suggest in this case is not easy<br>&gt; because there is a well accepted implementation of the Collection<br>&gt; hierarchy... we should look for another problem to apply your idea
<br>&gt; without &quot;noise&quot;... I keep that in mind and offer your idea to other<br>&gt; students.<br><br>I think it is *very* easy to do what I proposed as long as you are clear<br>what your goals for the refactorings are other than &quot;use traits&quot;. If
<br>your goal is, for example, &quot;minimize code duplication&quot; it&#39;s clear how to<br>do this without traits. If it is &quot;minimize number of entities&quot;, it&#39;s<br>clear, too. So is &quot;restructure into more useful/generalized entities&quot; or
<br>&quot;unify the interfaces&quot;. As long as you are clear on what goals you&#39;re<br>actually trying to achieve it&#39;s pretty clear how to achieve these goals<br>with or without traits.<br><br>Cheers,<br>&nbsp;&nbsp; - Andreas
<br><br></blockquote></div><br>