Against package removal

Anthony Hannan ajh18 at cornell.edu
Thu May 8 17:34:59 UTC 2003


The latest updates include package removals.  What does this buy me
except a smaller image file?  Who cares how big the image file is
especially once its downloaded.  Hard drives are big and virtual memory
only loads what is used.  So the only benefit is quicker initial
download, which is just a one-time event.  After that, you can download
incremental updates.

The costs of package removal are large.  It adds more management
overhead.  You have to manually find and load what you want, and
manually resolve potential conflicts.  But more importantly, you can no
longer find all senders and implementors of a class/method.  This makes
it hard to confidently make changes since you can no longer see all
dependent code.  With a full image, I find all dependent code and make
changes accordingly.  This allows me to make wholesale changes,
confidently.  I wouldn't be able to build a robust closure compiler if I
didn't have Etoys, MessageTally, ProcessBrowser, ImageSegments, etc.
loaded because I wouldn't know to update them to work correctly with the
new closure compiler.

I do agree we need modules in the image to better structure our code,
but the modules should all be in the same image so we can see all
dependents (to confidently make changes).

If you still want to reduce the size of the initial download, you can
build a distributed image, so only objects that a client uses are
downloaded.  I know this is hard but a distributed shared image has
many, many other benefits that make it worth while.  I believe a
distributed shared image of objects is the future (and should be our
vision).  Web Services is moving in this direction.

So I recommend:
1. Keep a single full image.
2. Add module framwork to the image (a la ClassBoxes).  Modules not
only facilitate better structured code, but allows different behavior to
co-exist in the same image without clobbering each other.  The module
framework can be added without displacing the current behavior
structure, allowing both structures to coexist and collaborate.  Then
classes and methods can be moved to modules as desired.
3. Work on distributing the image (using technology found in Magma,
rST, etc).  This will allow us to share the same image and build a
collaborative world (a la Croquet).

Cheers,
Anthony



More information about the Squeak-dev mailing list