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