ducasse stephane wrote:

> I have problem to see if keeping changes sets is really the way to go and
> how deltaModules are related to class extensions and modules them.
> I will discuss with Andrew to see if we can come up with a common
> understanding.

It's more like change sets will be left untouched, they will continue
working like they do now.

> ****The key point of the email is here ******
> Have you something like in Ginsu that sorts the classes into modules
> according to a spec? And put apart the methods that violates the visibility?
> Because like that you can design you modularization and check if this is ok
> then identify the problems.

Yes, ModuleRefactorer and subclasses do the sorting. There are also various
code analysis methods to analyze how references are made.

> Ideally I would have been great to get this work sponsored by the squeak
> foundation. Put in the room a bunch of excellent guys and wait one or two
> weeks...;) because this would be the best way to do it.
> 
> For the modularisation I think that we should take care about the
> propagation of versions among dependent modules. The idea is that if AV1.1
> depends on BV2.3, BV2.3 on C9.0
> Then everytimes you change C to a newer version you will have to change all
> the other versions. So the idea is that the kernel should be more stable and
> having a different change frequency than the its dependent.

This sonds very much like what I wrote in my architecture proposal at
 http://minnow.cc.gatech.edu/squeak/2057, about using an "onion-skin" module
architecture for the image.

>> In general I agree. But this won't work before the system has been untagled.
>> Since the system is tangled now, I'm afraid you cannot fix one area, say the
>> compiler or Morphic, without also touching other parts of the system. Like
>> you wrote, untangling Morphic also means changing the compiler, etc etc. So
>> this will be a messy process indeed.
> 
> That's why we should identify priorities and for example simply remove bad
> code and tangle thing unnecessarily. I was thinking about this GifReader
> References and other.

Yes indeed, we need priorities. I suggested a few in the above web page.

>> I meant that the code of Ginsu itself most likely changes a lot of the same
>> methods that this code does.
> 
> I do not see it. Ginsu does not change code.
> 

When you load the Ginsu change sets into the image then surely the fileIn
modiifies existing methods in the image to make Ginsu work.

Henrik