[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
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).
Other projects on the go...
System-InstallStreams - a parallel/heiarchical version of updates
(competed)
System-Packaging - a refactoring of all fileOut code into
PackagingFileOut.
- tidy up of fileout code from around the image
- (un)loadable replacable in one place.
- Used to craft fileOuts without using the changesorter tools.
Keith
More information about the Squeak-dev
mailing list
|