Hi Andreas,
 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.
 At the same time it will allow us to gain experience with traits and
"measure" if it is a good tool or not.
 Here is a copy of the process we will follow (I sent it in other mail):

> 1) Take a concrete class of the Collection hierarchy, for example
OrderedCollection
> 2) Create a new class (ie. XOrderedCollection) with Object as super class
> 3) Take a message of the ANSI Smalltalk of the selected class
(OrderedCollection)
> 4) Write a test, make it work with the selected class (OrderedCollection)
> 5) Make the test written in 4) work with the class created in steep 2. (
XOrderedCollection)
> 6) Repeat 3,4 and 5 until all messages of the selected class
(OrderedCollection) are implemented in the other class (XOrderedCollection)
> 7) Select another concrete class from the Collection hierarchy (for
example Array) and repeat steps from 2 to 6.
> 8) Repeat steep 7 until there are enough new implementations to infer
traits.
> 9) Refactor the new classes into traits... and play with the model until
we feel comfortable with the result.
>
> To put a limit in the project, they are going to implement just the ANSI
Collection hierarchy >(remember that it is a master thesis...)
>
> We thought that doing it this way the new implementation is not going to
be "guided" by the >old one, we will just keep the concrete classes names
but not the hierarchy necessarily...
>
> Please, feel free to let us know what you thing about this process, if you
have other ideas, >etc.

Bye,
Hernan.

On 9/6/07, Andreas Raab <andreas.raab at gmx.de > wrote:
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070907/0200eb71/attachment.htm