About 3.6 alpha process: to break the less

Daniel Vainsencher danielv at netvision.net.il
Wed Jun 4 12:57:51 UTC 2003


diegogomezdeck at consultar.com wrote:
> IMO, This is not the source of the problems.  The source of the problems is
> the extreme-minimalist approach that caught us.
...
> We are trying to make the standard image smaller and modular but we have
> not support at all to do that.  The current version of Squeak (and I'm not
> meaning the size of the image) allows the mess, so the mess will be there.
...
> We trust that a smaller default image will solve our problems but, in fact,
> we're creating more problems than then problems we're fixing.
...
> So, my short answer is: If we want a modular image [*], let's implement
> some modules mechanism before creating the pseudo-modules we're working
> on.  Probably we'll need also some type of namespacing support.
> 
> [*] I'm not sure I want to pay the price to have a modular image.  When I
> work with ST-Dialects with packages/parcels/application/yourNameHere I feel
> so constrained.  The monolithic image can have problems, but the freedom it
> gives is not present in more-declarative environments.

Modules are supposed solutions to several problems (and sometimes only
to subsets of these)-
1. Partitioning code so that one can reason about parts of it without
worrying about the rest. Fixing bugs in a Morphic application, you
should be able to say with certainty that this doesn't break the Morphic
framework. AKA limiting dependencies.
2. Allow groups to weasel their way out of naming conflicts. AKA
namespaces. If I have an Environment class that means a set of classes,
and you have one that represents an eco-sphere, and we really want our
applications to live in the same image.
3. Allowing deployment of bunches of code, according to a logical, fine
grained partition, but in a way that allows the user to just choose the
application, unawares of prerequisites.

Henriks module system tried to solve all three, and was very complex,
and I believe that anyone trying to solve all three at once will fail
for the same reason.

This is especially dumb because in the Squeak world, almost nobody is
actually complaining about problem 2 interfering with their day to day
life. Some people fantasize about how important it is, but we don't
really see the problem in practice.

Problem 3 is slowly drawing to a solution with SM.

Problem 1 will be solved when we have an explicit representation for
packages, and everybody is using it. PackageInfo is a partial solution,
but it isn't being used by that many people, which shows that what we
lack is not more infrastructure, but common ways of using what we have.

A subproblem of 1, that is, detecting whether some piece of code is well
partitioned, is somewhat helped by the use of MudPie, another example of
existing (though new and experimental) infrastructure that people are
free to use but dont. BTW, it's solution to 1 and the subproblem doesn't
require a hierarchial module structure, or any extra declarations of
dependencies, so you shouldn't feel anymore constrained by it than by
plain Squeak. In fact, it changes nothing about the way Squeak works -
it's just analysis, and you hook into it by writing one line SUnit tests.

So IMO, the question isn't "will someone save us by providing a magical
module system", the question is, are we making the best of what we have,
and thinking how to extend it?

Daniel



More information about the Squeak-dev mailing list