About 3.6 alpha process: to break the less

JOEL SHELLMAN joelhelenshellman at comcast.net
Thu Jun 5 01:20:48 UTC 2003


> 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 
> Morphicframework. 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, 
> finegrained 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.

Really? I've had to deal with #2 above all the time in the Java world. 
What is it about smalltalk that would make this less an issue? When 
you're working with hundreds or even thousands of classes (which 
happens often enough), it would be crazy to have to have them all named 
differently without namespaces, wouldn't it?

-joel



More information about the Squeak-dev mailing list