> 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.

I agree, but I would be happy with just some baby steps in the right
direction.  As I see things, there have been a number of attempts at solving
all of the problems, but none that simply try to make things a little better
than they are right now.

> > 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.

I agree here as well...just a warning.  In general, and as a matter of
principal, I never like to stop people from hanging themselves.

> ( 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 ).

I feel your pain.

> > 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.

Can you provide some pointers to Frost and Oasis...I seem to have lost them.

Again...I would like to find a simple and quick solution that makes no
attempt to solve the big issues, just one that makes life a little better
than it is right now.  I'd much rather have the simple and quick fix right
now than wait another year for the robust solution.  (of course, if the
robust solution does appear in a year, I won't hesitate to discard the
simple and quick fix)

- Stephen