[Pharo-project] How removing a class can broke DataStream/ReferenceStream/SmartRefStream

Schwab,Wilhelm K bschwab at anest.ufl.edu
Sat Oct 23 17:43:51 EDT 2010


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 at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck [marianopeck at 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>







More information about the Pharo-dev mailing list