On Wed, Feb 3, 2010 at 2:21 PM, Andreas Raab <andreas.raab at gmx.de> wrote:

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

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.

e.g.
Delay class startupPrerequisites ^#()
ProcessorScheduler class  startupPrerequisites #{Delay}
EarliestStartup class startupPrerequisites ^{ Delay. ProcessorScheduler }

WeakArray class startupPrerequisites ^{EarliestStartup}
EarlyStartup class startupPrerequisites ^{ EarliestStartup .WeakArray }

etc

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

+1


>
> Cheers,
>  - Andreas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100204/6d798aa2/attachment.htm