I wouldn't rely on such symmetry. Given the fact #printOn: is the only printing "instrumentation" available to show objects in debuggers, inspectors, etc. Most of the times it just shows a short representation of the object, not very useful to recreate an instance from such short string. Regards, Esteban A. Maringolo 2014-05-26 14:11 GMT-03:00 Rick Kitts <rkitts@loudhouse.org>:

I wanted to take a second to close the book on this. It turns out that storeOn:/readFrom: are not supposed to be symmetrical. printOn:/readFrom: are supposed to be symmetrical.

storeOn: generates a string that can be fed into the interpreter/compiler such that when it is executed an instance that is equal to the receiver of the storeOn: message is created. I’m trying to figure out how to do that now so I can convert a bunch of questionable tests of storeOn:.

Thanks for taking the time. I probably should have RTFMed this a little better before troubling the list.

—Rick

On May 23, 2014 at 11:15:43 PM, stepharo (stepharo@free.fr) wrote:

On 23/5/14 19:58, Rick Kitts wrote:

Hi. A basic question I hope someone can answer. This works:

— cut here --- | stream aInt |

stream := (String new:20) writeStream. aInt := 23. (aInt storeOn:stream) = (aInt class readFrom:(stream contents))

— cut here ---

This doesn’t (generates an error):

— cut here --- | stream aTime |

stream := (String new:20) writeStream. aTime := Time now. (aTime storeOn:stream) = (aTime class readFrom:(stream contents))

— cut here ---

To the question then. Assuming the second case isn’t wrong in some fashion I don’t understand, is it the case that storeOn:/readFrom: is supposed to be symmetrical for all classes? I ask it that way because there are a couple of Kernel classes where I’ve seen this to not be the case.

It would be nice that they get symmetric. because the goal of storeOn: is to recreate the same object. So if you have a fix please - sign the license agreement - open a bug entry - publish the fix.

TIA, —Rick