keith wrote:
> My choice of example is to simply start at the beginning.
> 
> 1. The current protocol, requires explicit registration and deregistration.
> 
> 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.
> 
> 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.
> 
> 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).

+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.

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.

Cheers,
   - Andreas