Q: Dealing with startup/shutdown lists
nygren at sics.se
Mon Jun 19 13:47:23 UTC 2000
Stefan Matthias Aust <sma at 3plus4.de> wrote:
> Is there any reason why #addToStartUpList: and friends require a class as
> argument? The startup list will only store symbolic names anyhow. But the
> current way leads to obsolete class references I'd like to omit.
> And why is there no way to remove an entry from this lists. Superfluous
> entries do no harm but I consider this, well, dirty.
> Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf
I have been thinking about this too. See the thread "startup/shutDown -
less then perfect".
My conclusion/opinion is as follows:
- This should be one not two structures.
- It should be dynamically changing to reflect what is at that time
needed to shutDown/startUp
- Since dependencies are crucial, it becomes a graph, it should be
- Traverse it in preorder for startup, postorder for shutdown. With a
dicitionary to ensure that
each object is only informed once.
- if there isn't already a general graphtraversal of this kind, make
one, they are useful
- the objects should be given information of the following type:
save / save and quit / quit / save and move (to other image) (future)
- It is well if people who decided that it should be classes in the
structure explains this, is there
a good reason for having only classes in this structure?
- one might consider to do this partially for image segments to be moved
out, but this seems
Since this can easily mess up images and there are lots of important
things I'm unaware of, I
decided to wait with this or leave it to somebody else. The above is a
good design I believe.
If somebody decide to do this, good luck!
More information about the Squeak-dev