[self-interest] Transporter

[Jecel Assumpcao Jr]

Thorsten,
> you can not solve this problem by ordering, or let me say you can
> easily construct a case in which ordering does not work anymore. I
> think it is a real hard task to move objects from one system to
> another via plain text.

This is very true, but the Transporter moves slots and not objects 
between systems. So it could find a proper order even for the case of 
circular references. Imagine that you add a slot "y" to "c" pointing to 
"b". We could have a file like this:

 - add a slot "b" to "globals"
 - add some slots to "b"
 - add a slot "c" to "globals"
 - add some slots to "c"
 - add a slot "y" to "c" and initialize to "b" (or "b copy")
 - add a slot "x" to "b" and initialize to "c" (or "c copy")

Hmmm... interesting.... I just tried your example again but 
initializing the "x" slot to "c" instead of "c copy" and the 
Transporter did the right thing.

Now I added the "y" slot as mentioned above and it still worked 
perfectly. So it is the "copy" that is giving the Transporter a hard 
time.

> I remember me that back in the good old days
> Servio had a solution for that. I was one of the goodies from their
> consulting group. I will try to find that old media and will hope
> that it is still readable. If I will find something useful I will
> send it to the list.

For binary formats this is easy to solve even if you deal with whole 
objects instead of slots.

> Do you use initializeTo: or don't you? When I remember me correctly,
> in Smalltalk all the construction stuff (create classes and methods)
> will be done first and all the initialize methods are called after
> that. I can try to implement this, but when initializeTo: is just a
> relict from the old days then it makes no sense to spend some effort.

Slot initializers in Self aren't quite the same thing as initialization 
methods in Smalltalk.

Perhaps you should reconsider using "copy" in your object descriptions. 
Since what is saved in the text description is the prototypes that are 
not meant to be used directly, it should make no difference in 
practice. Instead of using "b" directly, you will always ask for a copy 
of it. And inside b's 'copy' method will be code to copy the contents 
of its "x" slot (or else all b clones will share this value and that is 
probably not what you want). Right now b clones will start with a copy 
of a copy of "c" in their "x" slots. If you eliminate "copy" from the 
initialization code, then they will start out with a copy of "c" 
instead. If you want future changes to "c" to have an effect on future 
clones of "b", then this will do it (but your current code will not).

-- Jecel