[modules] {Image Shrink and Initialization}

Allen Wirfs-Brock Allen_Wirfs-Brock at Instantiations.com
Tue Aug 21 06:05:12 UTC 2001


Dave's experience with initialization pretty much matches mine although I 
have tended to prefer the constructive approach.

I think part of the problem people have had adapting to additive modules is 
that many existing classes libraries haven't been designed with 
initialization or re-initialization in mind. In many cases Classes (or 
probably more importantly mutually dependent sets of classes) that needed 
complex initialization have often been initialized with ad hoc doIts that 
aren't captured as reusable code.  Even, if the initialization code is 
placed in a change set or file-in as a do-it it tends to get forgotten 
because it doesn't show in the browser when looking at the class.

I think to make additive modules work reliably and repeatedly you need the 
following support for initialization:

1) Initialization code needs to be treated as first class code entities by 
the language and tools. Team/V did this and this is the reason that the 
ANSI Smalltalk language definition includes class and global variable 
initializers as language elements.

2) Initialization order needs to be well defined and repeatable.  Team/V 
and ANSI Smalltalk both claim this but only if a programmer completely 
specifies the initialization order in some inconvenient way.  This is one 
area where I think Java has done a better job.  The Java rule could be 
loosely stated this way: a class is automatically initialized the first 
time an executing method references the class by name.  I think the Squeak 
vm (or alternatively compiler) could be pretty easily adapted to support 
this semantics.  If anyone wants to try let me know and I'll try to provide 
a more complete "specification".

3) The development environment needs to support  placing a class (or 
module) into an uninitialized state. Note that this isn't strictly 
necessary in a pure runtime environment but it is quite essential for 
incremental development. Without it, you can't get an application into a 
predicable initial state as you add and modify code.  If you can't do this, 
you can't really test your initialization code.

As part of the ParcPlace-Digitalk Firewall project we successfully 
refactored the VisualWorks class libraries into a set of additive modules 
and were able to reliably and reproducibly generate a new fully 
functioning  VisualWorks images purely from source modules.  One of the 
hardest part of this refactoring was identifying the initialization 
requirement of all the classes and writing appropriate initializers. [BTW, 
I've always contended that these new images we generated were the first 
"Smalltalk-80" images that didn't share some image bits (via cloning) from 
Dan's original Smalltalk-76 images]







At 08:48 PM 8/20/2001 -0400, Dave wrote:

>There are essentially two approaches (both of which are useful and
>educational) to the problem of building smaller modular images.
>
>1. Start with the Image and Toss - The most popular has been to use a
>tool such as Stripper of Packager as we called it to remove classes,
>methods, instvars, globals and instances from the image. Packager also
>allowed renaming of symbols to smallints as does Pocket SmallTalk I
>believe. This approach avoids some of the initialization problem because
>it always starts from an initialized image. The problem is that it
>requires a lot of image and package knowledge expertise to perform the
>work and often developers unintentionally make it challenging to
>untangle an image so that it can be shrunk.
>
>2. Start with an empty Image and Add - the approach hear is to build up
>a set of modular images from a set of carefully selected classes. The
>problem of course with this approach is that it means that all
>interdependencies need to be fixed in the existing classes. Often people
>give up and decide to write their own new class libs as in  Pocket
>SmallTalk. The risk here is that once you decide to build an image you
>often own it for a lot longer than you intended. <grin>
>
>3. A compromise approach is to start with an image containing the
>initialized classes
>even if it is a cycle the they add in the classes carefully to build up
>the image. This
>finesses the hard problem of getting all classes to initialize
>themselves properly
>in some correct order. It also allows one to use the familiar classes
>even if the lack the modularity and independence that one might ideally
>like.
>
>It would be really useful to have an Image Analysis and Planning Tool
>which allowed one to understand the interdependencies between
>classes/methods and globals.  Ideally one would be able to plan a
>reorganize of the image without actually doing it in place. Being able
>to see the impact of many changes before making them would reduce the
>image FUD which one faces when trying to decide if you really dare make
>those sweeping changes that you think are either trivial or impossible.
>Hopefully the work by Stephan et al may come to play in such a tool. Our
>experience with running the Packager is that the more often people ran
>it the more they learned about problems in their image and the more
>concerned they became about writing more modular code.
>
>Regards,
>Dave





More information about the Squeak-dev mailing list