Help - Background - Remarks - Modularizing Squeak

Previous - Remarks - Next

Part of the great power of Smalltalk-based programming environments is the image: A great amount of accepted ("compiled") source-code that gets loaded when the system is started and is indeed the code that the Smalltalk-system at that moment can work with.

This has many advantages and at least three disadvantages. The disadvantages are that

(1) one may load a lot of code that one doesn't use
(2) the code in the image may get interdependent in ways that are unhelpful 
(3) the code in the image is not clearly divided in functional units.

The main problem is (2): Objects depending on objects depending on objects etc. as in a jungle of objects, of which each may be nice to see and somehow use, but which may be very hard to understand.

Modularity and modules are supposed to address these and some related problems, and should make it much easier to import and export into the image chunks of related code (modules) rather like one loads, runs and dismisses programs in an OS - the difference being that in Squeak one loads the source code and that one can inspect and alter it on the fly.

This is a large step and will take some time to get properly done, but when it has been properly done Squeak will very probably be considerably more powerful and also conceptually and manipulatively (so to speak) clearer, in that the basic conceptual unit becomes a module, made up of classes (made up of methods and data) that are intended to do a set of related tasks.

At present - Squeak 3.7 - Squeak has survived one effort to modularize it which turned out to be too difficult a task, and is now working rather well with another, called Squeak Map. This is a repository on the internet from which one may download packages of code into a working Squeak and install them.

Also, at present there are several projects going on in which the code in the Kernel and in Morphic is being improved. ("Refactored" is the Smalltalk term here.)

Previous - Remarks - Next