>In my opinion the issues of events, modularity, and exceptions are the
>leaky plumbing that needs to be addressed to make Squeak a great
>programming system (beyond merely good). I'll even go further: these
>need to be addressed (and soon) if Squeak is to grow and prosper. They
>need to be addressed to make Squeak ready for prime-time limelight --
>into which it seems (ready or not) about to head.

I absolutely agree with these points.  The problems, Paul described, mainly
how to start, how to make sure that the work isn't wasted, and how to
prevent multiple incompatible branches, are IMHO actually based in the lack
of modularity.

While I consider events and exceptions as important improvements, I'd
assign top priority to the modularity issue. So let's take that as an
example.  

If somebody would actually start working on this, it would probably have so
far-reaching consequences on the base system, that this would probably be a
rewrite of nearly the whole system. I don't fear that. But it would be a
time consuming task and it's absolutely unclear whether the work wouldn't
be made obsolete by introducing a new Squeak version in the meantime.  This
doesn't mean that this task can be only done by the Squeak central. It just
mean I've no solution (yet :-)

I've however the (perhaps wrong) feeling that "the Squeak central" doesn't
consider modularity as an important issue, for whatever good reason. So
this might become another problem. Probably not, but we'd have to find a
compromise I think, because this point has to do with motivation (how to
start) and prevention of splitting.

The technical problems are probably less than the organizational and
political problems. So let's discuss them first!

>Modularity allows one to deploy a Squeak system with the minimal
>footprint (like with only text handling classes and a compiler).

And also allows IMHO to build an image by adding modules and not by
stripping unwanted stuff. Perhaps it's only a psychological problem of
mine, but I've a better feeling when I can construct an image from
inter-dependent modules as if I've to guess what's probably not needed any
more. And I personally hate if base protocols gets poluted by somebody
adding his own special-private methods.

This is probably a different view of the image.  Some people take their
image as their own (castle), modifying everything without any exception, as
it fits the task.  I however see that my work separate from the image and
try to find a solution that would run with other programs in different
images, undisturbed.  Of course, I consider my opinion as the better one
;-)  I don't take the image as base code but as a class library, I better
not touch because next it shall also run with the next version.

>left over from ST-76). Addressing modularity also entails addressing
>version interdependency (something ENVY is good at).

And allows for 3rd party additions in a save and controlled way.

>One might also want to load precompiled
>modules as object code (not source) over the web.

Not only over the web...

>I'll conclude by mentioning that Python [...]

....has it all. It's only a different syntax and it lacks a nice and
integrated IDE. But otherwise, (provocation-mode on) Smalltalkers shouldn't
be as arrogant as ignoring every other language, falsely believing that
Smalltalk is perfect by all means (mode off). We should learn from Python
and adapt all working concepts, especially modules, namespaces and perhaps
a number of useful packages.


Back to modularity. First of all, we need a concept of modules and an idea
how to express this in Squeak.  Then we need to implement this and finally
modularize the whole system.  This task can become very challenging but a
first step might be just to make one big "Smalltalk" or "core" module.

Here's my definition of module: A module consists of a (possibly empty) set
of (instance and class) methods and a (possibly empty) set of class
definitions. Furthermore, there's a set of global variable definitions plus
initial values. Each method and class definition belongs to exactly one
module.  Each module has a dependency list, that contains at least all that
modules which contain the class definitions for all methods.

Each module defines its own class name space and can export a number of
classes to the pseudo module "Smalltalk." Each module can import other
modules to add them to that module's name space.  Optionally, classes and
methods can be declared as private (in the Java sense, that it not even
subclasses can access these methods), but at least for methods, this would
need VM support I think.

All browsers need to support modules. We'd need a module browser (instead
or additional to the system browser) and each browser need to allow to
change a classes or methods module. As you might see, change sets and
modules are somewhat related here.

For implementation, I'd expect something like VisualWorks parcels - done
correctly. Instead of one general source file, each module has its own
smaller source file plus a binary file.  The change file still exists, but
it will not contain code that isn't also saved in some modules.  With
parcel-like modules, binary-only modules came without any additional cost.

The base image (if we need one, this functionality could also be
implemented as a primitive) should contain just enough code to read in the
first binary module and start the execution.  This module would contain the
core classes like Object, Boolean, etc. After bootstrapping the system,
more file support could be loaded which then would install the source and
otherwise prepare the development system (loading a compiler, the GUI, a
debugger, the browsers, etc)

Of course, you'd be able to save the image once bootstrapped from binary
modules.  All code will be copied to the image, if no source modules are
available, code is decompiled, changes go to a change file, if you save a
module, a new source module is created and so on. The system should however
check for the existance of source modules and warn the user because this is
always a source of errors.

Comments?
bye
--
Stefan Matthias Aust  //  Are you ready to discover the twilight zone?