Hi Daniel,

If you look at environments/layers as configurations and classes as
the loadable units, then a configuration specifies which versions of
which classes to load.  It may do this by including (inheriting) other
configurations then adding/overriding classes itself.  If the user
switches configurations it is very reasonable to expect things like the
world menu to change.  However, if he stays in his own personal
configuration and just changes which other configurations it inherits,
then if he inherits two configurations that have two different versions
of the world menu then an exception will be raised because it is
ambiguous.  So conflicts will be raised and must be resolved.

Ideally there would only be one version of each class, and configurations
would just specify which ones to load.  But allowing different versions is
needed, because full collaboration is impossible.  New class versions can
be submitted as replacements for originals, and the best way to do that is
to put the new version in its own configuration so others can inherit
from it and test it.  Then when it is tested and accepted it can be
promoted to the original configuration.

Remember, I am still a proponent of class extensions that are actually
separate behaviors/classes in a multiple inheritance hierarchy.  This
way new versions of classes are just changes and not additions of new
behavior.  With class extensions as separate classes, we only need
configurations and classes, eliminating the need for a third intermediary
concept (packages).

As for multiple images, even if memory is cheap we don't want to waste
it, so PDA users can load and run as many applications simultaneously
as possible.  So I really think we should strive for one "operating
system" image.  And as for a safer non-crashing image I think layers/environments/configurations would actually help this.  When a
critical error happens, the user can be moved to a safe configuration
automatically.  He would still be able to inspect the damaged
configuration because its still in the image, its just no longer running.
See
http://web.media.mit.edu/~lieber/Lieberary/Softviz/CACM-Debugging/Kansas/Kansas.html
for an example of this done in Self.

Finally, without different configurations allowed in the same image how
do you expect to handle Squeak Projects, and switching between them
easily?  The current mechanism is very fragile and needs to be fixed. 
Today, projects can only be loaded in images that are sufficiently
similar to the image it was created in.  If certain functionality is
missing or changed the project will break.  It has no way of determining
or loading the base image it depends on.  It only know local changes it
made inside its project.

Cheers,
Anthony


Daniel Vainsencher <danielv at netvision.net.il> wrote:
> Ah here I definitely disagree - I think this is a huge landmine.
> 
> Whether people come to use a layered system for it's real benefits or
> not, I think it would be a disaster if people use it to ignore trivial
> incompatibilities between packages.
> 
> Remember that one of the great benefits of free software development is
> the testing. It's a critical part of the magic. For a modular
> environment, as Squeak is already headed to be since the day SqueakMap
> is online, integration testing is a large part of the issue. 
> 
> Where two packages need significantly different functions, they should
> be using two separate, mutually neutral actual mechanisms. Where two
> packages need slightly different versions of the same thing, this needs
> to be visible, slightly painful for all involved, until it is resolved. 
> 
> I'll give you a concrete example - if each package, as part of it's
> layer, should bring in it's own version of the TWM>>openMenu, everything
> would "work", and the user might go mad before understanding why it
> keeps changing on him. The solution is to find these areas of conflict,
> however small, and redesign them for cooperation. Not to apply a
> one-size-fits-all plaster that allows all packages to ignore one
> another.
> 
> The real solution is for package maintainers to avoid patching other
> packages, in your package, instead submitting patches to the upstream
> packages maintainer. And concurrently, to give the user tools to notice
> and control when this is happening.
> 
> Memory is cheap, and cheaper every day.
> 
> For an OS, it gets unfixably stuck too often. We have issues to solve here 
> much before we need layers.