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
|