I mention closures specifically because that's what an object is. An
instance of an object closes over the class that defines it, so just
serialising the object means that you need the same context (same
version of the class) to deserialise it. Look at the hoops Fuel have
to go through. It's not easy.

It's not quite the same as a database migration because you store your
data _in the database_. This problem is more like "how do I load this
snapshot of the database, when the db schema has since changed?" And
there, the problem's easier: take the schema that that snapshot used,
and figure out the migrations between that version and the current
version. Play those schema changes over the snapshot and you're done.
Except _here_ you don't (can't!) know the version of the schema/class.
So you roll a custom map and pray.

Anyway, we're digressing off the point of this thread, which is that
System depends on MorphicExtras, which is ridiculous.

frank

On 13 May 2013 18:47, Bert Freudenberg <bert at freudenbergs.de> wrote:
> This is not specific to closures, but rather about dealing with change. Same thing as e.g. Rails' migration support.
>
> - Bert -
>
> On 2013-05-13, at 19:35, Frank Shearar <frank.shearar at gmail.com> wrote:
>
>> Right. In which case what we need to do is recategorise the methods.
>> #alansTextPlusMorphbosfcebbmsopssrsggshtt0 belongs in *Morphic-Extras
>> because its mapped class, TextPlusMorph, is in that package, and so
>> on.
>>
>> I can appreciate the cleverness of the hack, while being mildly
>> distressed at its fragility. But that just goes to show you that
>> serialising closures is hard.
>>
>> frank
>>
>> On 13 May 2013 18:22, Bob Arning <arning315 at comcast.net> wrote:
>>> They are used when reading a file containing a reference to a class which no
>>> longer exists. These methods map the old class to a new one. The selector is
>>> the name of the old class (first letter downshifted) followed by the first
>>> letter of the inst var names at the time that object was written to the
>>> file. See the #writeClassRename... methods for creation. See #mapClass: for
>>> usage.
>>>
>>> Cheers,
>>> Bob
>>>
>>>
>>>
>>> On 5/13/13 12:57 PM, Frank Shearar wrote:
>>>
>>> SmartRefStream has messages like
>>>
>>> * alansTextPlusMorphbosfcebbmsopssrsggshtt0
>>> * abstractStringx0
>>> * layoutMorphbosfcepbbochvimol0
>>> * layoutMorphbosfcepcbbochvimol0
>>>
>>> and many others. The timestamps go back a ways, some to 1998. Squeak
>>> 4.3 has them. Where'd they come from? More importantly, are they just
>>> junk that we can remove?
>>>
>>> frank
>
>
>
>