[squeak-dev] Re: about startup

Igor Stasenko siguctua at gmail.com
Thu Feb 4 08:54:54 UTC 2010


On 4 February 2010 00:21, 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.
>
> 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.
>

I am a bit concerned about logic of prioritization of startup/shutdown lists.
You can't implement the simplest 'run before anything else' rule,
since there's no guarantees that any other package would not want to
do the same and hence you'll get a conflict.
Maybe, a System should throw an error, if it finds that there are two
or more things which want to run on same priority, and signal the
user/developer to solve a conflict before saving an image.
Then, at startup, a system won't need to guess what follows what,
since it is _always_ instructed by user explicitly.

So, a proposal is, that classes , which want to take part in
startup/shutdown phases providing a 'guessed' priority.
The system collects all such classes and in case of conflict, _always_
asks user to solve it, and then using this slightly modified (but
explicitly ordered) list to perform startup/shutdown.

Still, even without it, Keith's approach is absolutely much better
than existing one.

> Cheers,
>  - Andreas


-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list