Jecel Assumpcao Jr
jecel at merlintec.com
Thu Jun 6 19:18:04 UTC 2002
> 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
> 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).
More information about the Self-interest