[self-interest] Transporter

[Jecel Assumpcao Jr]

On Wednesday 05 June 2002 15:03, Thorsten Dittmar wrote:
> I'm not sure if I do some thing wrong or if it is a bug.

It is a bug.

> Here the situation:
> I have a module with 2 prototypes (b and c).
> Prototype b has a slot named x.
> I use the annotation mechanism to initialize x as a copy of c.
> So far so good... Now file out the module and use bootstrap read:
> 'filename' From: 'dictionary' to file it in.
>
> I will get an error because x can not be initialized because the
> prototype c is not installed at all at this moment.

The problem is that the module created the objects in the wrong order. 
I tried this and got the same error as you did, and then I did it again 
but with the objects named "f" and "e" instead of "b" and "c" and it 
worked as it should.

If you look at the object "transporter fileOut slotSorter" (specially 
in the method 'topoSortFrom:Path:IfCycle:') you will see that though it 
starts out with a simple alphabetical order for the top slots in a 
module, it makes a great effort to find all dependencies and reorder 
things to fix them. Unfortunately it doesn't seem to handle this 
(rather common) case.

> Maybe I misused the annotation mechanism. Of course I know a
> workaround, but I want to know what the right way for the not so
> uncommon situation is.

One workaround is to choose top level names so things fileOut in the 
right order. To get back a module that would otherwise be lost you 
might want to edit the .self in a text editor, though this is a lot of 
work and the problem will reappear the next time you save the module.

I ran into this myself when working in tinySelf 1 back in 1997, which 
was one of the reasons I never finished debugging it. On the other 
hand, I wrote several other applications and my trainees did too and 
none of them had this problem. It depends on luck (what your objects 
are named) and style (whether you use "InitializeTo:" annotations or 
not).

-- Jecel