These are the 4 items which were [approved] last week, plus one which 
Daniel approved about a month ago that I somehow missed.  (The subject 
line for that one was munged a bit, though... I'll use that as an 
excuse. ;-) )

- Doug Way


-------------------------------

5241instrPrinter-md -- Marcus Denker -- 8 April 2003
A refactoring for InstructionPrinter,
AbstractInstructionPrinter and InstVarRefLocator:
AbstractInstructionPrinter:
moved the instVar and a method into InstVarRefLocator, now this class 
can
be used as a Abstract Superclass for
both InstructionPrinter and InstVarRefLocator
Renamed to InstructionClient (c.f. VisualWorks).
InstructionPrinter: refactored to be a
subclass of InstructionClient"

5242HashChanges1-SqR -- Andres Valloud, Stephan Rudlof -- 13 August 2002
Goals:
Implement an improved hash for large integers.
Refactor/rename some hash methods to make them more intention revealing.
Pass 1 - Implement refactoring so it can be bridged later.
sr: I have changed #byteAt: to #basicAt: to make it Slang compilable 
(and changed some var names)."

5243HashChanges2-SqR -- Andres Valloud -- 13 August 2002
Pass 2.  Implement LargePositiveInteger>>hash.
Rehash sets as appropriate."

5244HashChanges3-SqR -- Andres Valloud -- 13 August 2002
Pass 3.  Make String and ByteArray use the
refactoring instead of the original
implementation."

5245MorphicClsComments-efc -- Eddie Cottongim -- 7 March 2003
Class Comments for Morph, ImageMorph, SimpleButtonMorph and 
StringMorph. These were subject
to review and editing on the swiki, and thus should be fairly 
comprehensive."

5246Sibling-dup-tk -- Ted Kaehler -- 11 March 2003
Whenever you ask for a sibling instance of a Player in an EToy, the 
Players of the new object is an instance of the original Player class, 
instead of having a new class.  When you duplicate a morph the holds a 
set of siblings, there was bug that made the new objects not be 
siblings.  This fixes the bug.  Alan wants this fixed for the cells of 
a Tic-Tac-Toe game.
	To test, make a playfield with a blob in it.  Make a sibling of the 
blob.  Tell the playfield to 'make sibling instance'.  All four blobs 
will remain siblings.
	In addition, the production of a sibling instance is now cleaner.
	(Updated to fix a conflict with the 5240 MCP update. -dew)"

5247VeryDeepCopyUsing-tk -- Ted Kaehler -- 13 May 2003
Object>>veryDeepCopyUsing: is a utility method.  When you have a 
complex data structure, involving several custom classes, veryDeepCopy 
on a subpart may not do what you want.  When you veryDeepCopy one of 
your objects, it does not know which instance variable are actually 
pointers back to a 'global' object, which should not be duplicated.  
The 'parent' links in a tree are an example.  These can be handled by 
creating veryDeepInner: and veryDeepFixupWith:.  However, it may be 
easier to make a custom veryDeepCopy method.  In it, you create a 
DeepCopier, and store into its references dictionary with (globalObject 
-> globalObject).  Then you want to start a veryDeepCopy using that 
DeepCopier, and calling veryDeepCopyUsing: is the way to do that."