<br><br><div class="gmail_quote">On Wed, Feb 3, 2010 at 2:21 PM, Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">keith wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My choice of example is to simply start at the beginning.<br>
<br>
1. The current protocol, requires explicit registration and deregistration.<br>
<br>
2. When you want to slice up the image into small pieces it is a pain to have a dependency elsewhere. Smalltalk/SmalltalkImage initialize is a prime example, where the Balloon-Collections could be removed (from cuis), but for their mention here.<br>
<br>
3. the addToStartUpList: aClass after: anotherCompletelyUnrelatedClass idiom is simply asking for one package to be unnecessarily dependent upon another, just for the sake of setting the ordering.<br>
<br>
4. The implementation code is fairly complex, compared to the alternative. There are some fringe cases and validation cases dotted around the image which would not be necessary. (e.g. on renaming or removing a class).<br>
</blockquote>
<br></div>
+1 to all of the reasoning. Two things I'd do in your implementation is to a) use symbolic names for the priorities (so that one can say NormalLaunchPriority, EarlySystemStartup etc. instead of numbers) and b) have a unique order inside a priority group (say alphabetical) so that there's *some* defined order by which things get executed. The latter avoids suprises if there happens to be a dependency between initializations; at least it'll be always the same and you can plan for it accordingly.<br>
</blockquote><div><br></div><div>An alternative is for a class to define its prerequisites, which classes it requires to have been initialized first for startup, and which classes it should be shut down before on shutdown, and do a topological sort (reverse the depth-first walk of the prerequisites digraph). Then there's no need for priorities. One could then add classes whose function it is to define positions in the list. So your NormalLaunchPriority, EarlySystemStartup et al would become classes that define in their prerequisites which system classes are stated up in their phase, and other classes could use these as their prerequisites instead of directly mentioning classes that might or might not be present in an image.</div>
<div><br></div><div>e.g.</div><div>Delay class startupPrerequisites ^#()</div><div>ProcessorScheduler class startupPrerequisites #{Delay}</div><div>EarliestStartup class startupPrerequisites ^{ Delay. ProcessorScheduler }</div>
<div><br></div><div>WeakArray class startupPrerequisites ^{EarliestStartup}</div><div>EarlyStartup class startupPrerequisites ^{ EarliestStartup .WeakArray }</div><div><br></div><div>etc</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
BTW, I'm *very* happy to see that you've found a way by which you feel comfortable contributing to Squeak. Your help is most welcome.<br></blockquote><div><br></div><div>+1</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Cheers,<br><font color="#888888">
- Andreas<br>
<br>
</font></blockquote></div><br>