Getting rid of metaclasses (Was: Behaviors vs Modules)

Hannes Hirzel hirzel at spw.unizh.ch
Fri Mar 1 01:31:04 UTC 2002


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




More information about the Squeak-dev mailing list