source code mgmt

Les Tyrrell tyrrell at canis.uiuc.edu
Thu Dec 7 18:47:05 UTC 2000


Stephen Pair wrote:

> There's been a lot of talk about robust source code managment and modularity
> issues...maybe there's something much simpler that could help ease the
> burden a bit until a more robust modularity solution is available.
> 
> How about achieving these goals:
> 
> 1.  Allow a package of source code to be installed and uninstalled in such a
> way that un-installation results in all affected classes and methods being
> returned to their original (pre-install) state, unless some other package
> had subsequently (to the installation) modified some common source code
> elements.

Under no circumstances should the host environment ever be corrupted by
a package being loaded or unloaded.  Oasis does this by loading code into
a separate environment, not into the host class libraries.  However, cross-
environment references need to be managed to enable clean unloading.

> 2.  Allow a package to have a name and a version number.
> 
> 3.  Enable the system to track all source code packages that have been
> installed (including a *version number*).
> 
> 4.  Enable a package to declare other packages that it requires as
> pre-requisites (and warn on load if the pre-requisites are not satisfied)

yes- but no more than a warning.  No matter what, one must always be able to
bring packages into an environment where at a minimum they can be browsed.
The tools available can then advise about the completeness of the package,
but must not interfere with your interaction and manipulation of that package.

( Real world example: resurrecting Frost from Envy code was a righteous
b*tch due to Envy preventing me from loading Frost's applications- required
prerequisites had long since been lost ).

> 5.  The base package could (for now) be the entire Squeak Central release.
> A package would specify which Squeak release (or releases) are acceptable
> pre-requisites.
>
> 6.  Loading an unloading of a package could be done by a default mechanism,
> or be customized by package load and unload methods.
> 
> This would not solve all problems of modularity...particularly the problem
> of having more than one version of a package loaded simultaneously (which
> would presumably require better namespace capabilities)...but, it would be a
> start I think.

This is not a big problem- Oasis can do this in VisualWorks already, and similar
techniques could be used in Squeak.  I had planned to open-source Oasis by now,
but have been distracted recently by Frost.

A bigger problem is initialization of a base package- a fundamental characteristic
of a base package should be that it will initialize its classes cleanly.  Of course,
that should be a fundamental characteristic of any package.

- les





More information about the Squeak-dev mailing list