[Pharo-project] How removing a class can broke DataStream/ReferenceStream/SmartRefStream
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:
Time: 23 October 2010, 10:07:35 pm
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