SmartReferenceStream is indeed complicated, but it is also poorly designed. Dolphin's binary filer intuitively places versioning (of the serialized data streams) on the class side of each serialzed class or a proxy for same. The result is that the filer itself does not change as the classes it marshals change shape, nor does it try to think for the user and programmer or ask end users to debug conversion problems. If you think things are bad now, wait until you start stepping on Stef's and Sig's changes (for example purposes only) to the filer. SIXX tackles some of this, but I have yet to run into it, perhaps in part because it seems to work more by messages/aspects than by instance variables as Dolphin's filer. It is very possible that I have yet to push SIXX far enough to see problems, but I recommend having a look at it. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck [marianopeck@gmail.com] Sent: Saturday, October 23, 2010 4:08 PM To: Pharo Development Subject: [Pharo-project] How removing a class can broke DataStream/ReferenceStream/SmartRefStream Pharo core version: 12210 In Pharo 1.2, the class SoundBuffer was removed. DataStream >> initilize was modified, and just added an Smalltalk at: ifPresent: for such class. However, this broke DataStream and all its subclasses. This is because DataStream is chryptic, impossible to understand, and impossible to change. The changed affected when trying to write compiled methods (just by chance, because they were after in the list, of SoundBuffer). I've spent 3 hours to fix this bug grrrrr Fix in Inbox: Name: SLICE-Issue-3147-RomovingSoundBufferBrokeDataStream-MarianoMartinezPeck.1 Author: MarianoMartinezPeck Time: 23 October 2010, 10:07:35 pm UUID: c4f1cf01-b8b8-471d-b3c2-e67bdf08d8e5 Ancestors: Dependencies: System-Object Storage-MarianoMartinezPeck.112 Fix to issue 3147<http://code.google.com/p/pharo/issues/detail?id=3147>