On 13 May 2013 19:16, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On 2013-05-13, at 19:58, Frank Shearar <frank.shearar at gmail.com> wrote:
>
>> 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.
>
> Agreed.
>
>> It's not quite the same as a database migration because you store your
>> data _in the database_.
>
> To the contrary, it is exactly the same. Here you store objects in project files, whereas the logic for reading them resides in the image.
>
>> 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.
>
> That is just how it works in Squeak.
>
>> Except _here_ you don't (can't!) know the version of the schema/class.
>
> Yes, you do. Each class version is stored in the project file.
>
> Classes in Squeak are versioned precisely for that reason (see implementers of #classVersion).

Ah. Font glitch. I thought the methods had a capital O on them for a
class var, not a zero for a version number.

> A newer class is supposed to be able to read instances of its older versions. It provides data migration methods. Only for classes that went away completely do we need to know which "modern" class took over: that is what these methods in a known place are for. And back in the day when people used project files on a regular basis this used to work pretty damn well. E.g., when exporting a changeset that affected class layout, the system used to warn you that you should better add an migration method for backwards compatibility.

Right, so these migration methods will be
#convertToCurrentVersion:refStream:? New things learned every day!

>> Anyway, we're digressing off the point of this thread, which is that
>> System depends on MorphicExtras, which is ridiculous.
>
> This predates the image-carving, so yes, the methods need to be classified properly.

Done.

frank

> - Bert -
>
>>
>> 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
>>>
>>>
>>>
>>>
>>
>
>