Of course, this is crucial to the modules code. I've been following the modules discussion here, but here's my fundamental concern: How do I end up not programming on quicksand? From what I understand so far, the modules solution is about keeping different chunks of code and data in a seperate space that you can 'swap' in. I can see how that works if the module is independent and does not change the 'base' image code. Where I get lost at is how all the modules interact when they fly back into the image, and start changing that base code, potentially over writing each others changes. If you don't have a stable base, and some protocol saying how you can attach changes onto that base, it turns to quicksand real quick.
You said it: they *potentially* overwrite each other's changes. This is a potential for excitement, not a problem to be feared. Live! It's the age of cowboy coding, and should be cherished. Start your programming sessions with a big "yeeehaaa!", not by putting some quiche in the microwave.
-Lex
On Thu, 28 Feb 2002, Lex Spoon wrote:
Of course, this is crucial to the modules code. I've been following the modules discussion here, but here's my fundamental concern: How do I end up not programming on quicksand? From what I understand so far, the modules solution is about keeping different chunks of code and data in a seperate space that you can 'swap' in. I can see how that works if the module is independent and does not change the 'base' image code. Where I get lost at is how all the modules interact when they fly back into the image, and start changing that base code, potentially over writing each others changes. If you don't have a stable base, and some protocol saying how you can attach changes onto that base, it turns to quicksand real quick.
You said it: they *potentially* overwrite each other's changes. This is a potential for excitement, not a problem to be feared. Live! It's the age of cowboy coding, and should be cherished. Start your programming sessions with a big "yeeehaaa!", not by putting some quiche in the microwave.
-Lex
Is this meant ironically? Partly probably...
However an important aspect of the modules approach is to support a community process of rather loosely coupled individuals contributing. We need mechanisms which allow us to easily see what others have been doing and accepting or changing things. For me the original write up by Hans-Martin Mosner about collage was very revealing. http://minnow.cc.gatech.edu/squeak/745 (written end of 1999)
He speaks about the weaknesses of ChangeSets.
Then he writes
You could compare the way an ENVY Smalltalk image is built to a jigsaw puzzle: All the parts have to fit together, but they must not overlap. This works fairly well for closed projects where you can assign the work to different people, and they can talk about overlaps and possible redundancies to sort them out. For independently developed applications and base fixes, this is much more difficult. Collage, on the other hand, is designed around the metaphor of a stack of overlapping layers, which may partially or completely mask underlying layers. Elements in collage layer are a superset of the things that can go in a .st file or ChangeSet: they may be a class or method definitions, changes or removals etc. But Collage elements could also be inst var or class var additions, removals or renamings, class renamings, pool and pool var definitions. In the case of conflicting definitions, the uppermost layer wins. This is just like the way .st files work. But you can reorder or even uninstall layers, thereby unmasking previously masked definitions.
I see this concept show up somehow in the DeltaModules. Exactly how I do not know yet.
-- Hannes
squeak-dev@lists.squeakfoundation.org