[modules] Cutting the knot
Henrik.Gedenryd at lucs.lu.se
Mon Oct 1 09:04:21 UTC 2001
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
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.
More information about the Squeak-dev