Very helpful for understanding the squeak jungle, however we cannot stop here 
and say, OK, we have resolved our modularity problems.

Modularity problems come when we start having different versions for the same 
class>>method, and this is unavoidable in a living system.

Either two different applications i want both in my image have such a clash 
directly, or they will require a third utility of different version...

Mathematically, we could write the problem as:
- we have a set of TestCase we would like to fulfil (good idea)
- we have the set of class>>method ever written in Squeak
- each class>>method has a set of versions, class>>method#n
- only a single version can exist in the image
- which partition of class_i>>method_j#n_k will light all our TestCase to 
green ?

Let us imagine we have an enhanced version of Spoon to solve this problem.
When pulling methods in, inheritance must be taken into account, removed 
methods are as important as added methods:
if we have a class hierarchy A > B > C, all implementing versions of method m, 
and a TestCase doing (C new m), we will have to check all partitions of set 
(A>>m,B>>m,C>>m). Each partition being divided into all combinations of 
versions m#i...

Too much combinatorial, i think... It could be feasible only if we group 
methods in indivisible units (packages...) in order to reduce problem 
complexity.

And, this is a rather static view. Our modules may also trap the MNU and 
process the case normally (hence we cannot eliminate the empty partition in 
above case). Our modules may also well generate classes and methods 
dynamically, like already possible in a true dynamic environment like 
Squeak...

And last, this is also an ideal case, most applications simply do not have 
such a TestCase collection covering 100% of their capabilities. Yes, they 
should, but how do you write GUI test like when i push this button, a window 
open with contents equal to...?

I did not speak of global variables (class variables mostly), which also cary 
a state that can make our TestCase either succeed or fail...

Spoon is promising, but won't solve everything

Nicolas

Le Mardi 23 Mai 2006 20:50, Ralph Johnson a écrit :
> >        Almost; the test case is started from the full image by sending a
> > message to the appropriate remote object in the minimal image, and the
> > minimal image records the transfers with a module (somewhat in the
> > manner of a changeset).
> >
> >        Module objects from different images know how to synchronize their
> > respective systems by comparing their contents, so, for example, when a
> > test case is finished, a minimal image could immediately transfer that
> > new behavior to another minimal image (which uses another new, empty
> > module).
>
> Is the module system new?  I didn't see anything in the December
> version of Spoon like that.  Maybe I just don't recognize it.
>
> It is a very good idea.  A module is defined as all the code that is
> needed to run a test suite.  To have a module, you must have tests.  I
> like it!
>
> -Ralph