[squeak-dev] Re: about startup

keith keith_hodges at yahoo.co.uk
Wed Feb 3 21:57:02 UTC 2010

> http://code.google.com/p/pharo/issues/detail?id=1918
> and I just saw that by accident so posting to pharo is a better way  
> if you refer to pharo as another fork.
> Now a question is what is wrong with the current protocol?
> Stef

Hi Stef,

This is intended to be a simple example, for the purposes of showing  
off the concept of how it is possible to develop a slice of  
functionality, and deliver the knowledge in a form usable by all  
forks. This is achieved by distributing the code, the integration  
code, and the cleanUp code separately.

My choice of example is to simply start at the beginning.

1. The current protocol, requires explicit registration and  

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

Other projects on the go...

System-InstallStreams - a parallel/heiarchical version of updates  

System-Packaging - a refactoring of all fileOut code into  
- tidy up of fileout code from around the image
- (un)loadable replacable in one place.
- Used to craft fileOuts without using the changesorter tools.


More information about the Squeak-dev mailing list