On 13.12.2011 15:35, Schwab,Wilhelm K wrote:
Henry,

Of course the old data do no know how to turn themselves into the current format.  But they do/should carry with them version information (can be as simple as an integer bumped with each change); the system uses that to tell which incremental reshapes to apply.  It works like a charm.

Putting the conversion methods in the deserializer is _possible_, but it becomes a huge mess over time, risks collisions, complicates packaging for everything that uses it, and the code is FAR better placed in the classes that are changing over time.  The latter becomes really obvious when one starts to use proxies.

Bill

Then we agree on all points, I just misread what you'd written :)

Cheers,
Henry



From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Henrik Sperre Johansen [henrik.s.johansen@veloxit.no]
Sent: Tuesday, December 13, 2011 5:55 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Cleaning up SmartRefStream use

On 11.12.2011 19:50, Schwab,Wilhelm K wrote:
When I last looked at SmartReferenceStream, it did two things that were bad:


(2) reshape code was placed in SRS itself, not in the class that is changing shape.  The thing that is being deserialized (which is when problems become apparent) should be in charge of the change.  It simplifies both packaging (fewer loose methods to consider, and reduced opportunity for name collisions) and it also helps with using proxies for special circumstances.

I'm not sure I understand/agree with what you are saying.
What has been serialized is (almost) always an older version than what you are loading into, in which case I can't really see how it can answer the question "How do I turn into the current version?" correctly.
Maybe there needs to be a split? Serialized version knows how to install itself as older versions (incase that's what you load into), while the image takes care if version in memory is newer than serialized?

TBH, I also feel it's better to put the "import old versions" functionality as methods on the class itself rather than have an omnipotent materializer with special methods for installing all versions of all known classes in the system, I mean, exactly in the serializer/materializer do you intend to put such logic for custom user classes?

Cheers,
Henry