Lex Spoon wrote:

> Some students in the Georgia Tech OO class are thinking of investigating
> and documenting parts of Squeak in order to get extra credit.  Here's
> your chance: what would you most like someone to dig into and then write
> up? 

> 
> The only constraint is that it must be something a student would have a
> chance of doing....
> 

I thought it might be useful to answer this on a general level.

I'd say documentation is particularly useful for parts that are not already
documented (particularly, in the Smalltalk-80 book[s], or the squeakbook),
either because they are new or have been changed since then. Also, that the
more "core" the functionality is, and the less likely the code is to change
fundamentally, the more useful documentation would be. (Perhaps this is
obvious and everyone agrees on it?)

Now what would this mean? Morphic is certainly a central new part, but there
are already (too) many different pieces on that.

I'd suggest the whole image segments/SmartFileStream/project loading complex
of various classes. (If not all, then any part of it would be nice.)

This because it could be very useful as a foundation for general modularity
mechanisms, but if they are to serve such a central function, then they
dearly need to be well documented. Just such a small part of this as
veryDeepCopy needs to be better documented. I have learned that part myself
but that was in the hard way. The part where GC is used to map out a part of
memory would be nice to have clearly explained as well. One shouldn't have
to understand the GC implementation to use that mechanism.

One piece of Morphic that is not yet documented is the drawing cycle. It is
also not exactly intuitive, it can be really hard to debug. It would be very
nice to have good diagrams and so on that explain double buffering and how
redrawing is triggered and when it is carried out, etc..

Henrik