[Modules] A proposal for Modules, Packages and Dependencies

Les Tyrrell tyrrell at iserve11.lis.uiuc.edu
Wed Aug 22 06:14:28 UTC 2001


I would like to throw in a few words of caution regarding a few things.

Smalltalk is an insanely impressive language/programming environment.  It has only a few rules, and somehow
manages to do an incredible job of staying out of my way when I am programming.  To me, Smalltalk is best
understood not as a programming language, or as a programming environment, but as a media for the liberation
and sharing of thought.  I concieve something in my mind, and the distance from my mind to a working model in
Smalltalk is amazingly short.  In time, I would like it to be shorter, but first things first.

I feel very strongly that anything we do to change Smalltalk should be done in the spirit of seeking ways to
further enhance the sharing and liberation of thought.  To me, this means that to the greatest extent
possible, each and every component in a system shall be given as much independent life as is appropriate and
possible.  If components become too tightly bound to one another in inappropriate ways, this freedom of
thought is threatened.  Thus, I feel we should look for ways to avoid this whenever possible, as well as ways
to correct this when it has already happened.

Thus, I have strong reservations regarding any scheme in which modules are given explicit information about
other modules.  This includes such notions as "pre-requisites", or modules "containing" other modules.  We do
not give classes explicit information about other classes- we do not force them to import method selectors
from other explicitly named classes before they can operate.   We do share selectors, but that is not the same
as telling a class that in order to operate it must first import SomeClass>>someSelector.  Instead, we rely on
the programmer and his tools to be sure that these other things will exist in the sea of selectors in which
the class is swimming.  Likewise, I feel that is inappropriate for any given module to be given the
responsibility for managing the accounting of which other modules are needed in order for it to operate.  I do
feel that it is neccessary to have such an accounting somewhere, but I believe that the roles of such
"configuration" objects and modules should be, and in fact are, very different.

To the best of my knowledge, no system has been built in this way.  All others that I am aware of do require
explicit configuration knowledge on the part of individual components, rather than tasking other objects with
this responsibility.  Although I have been taking this route in Oasis, I have not explored this very
thoroughly yet.  So, there would be a bit of risk in pursuing it.  So, for now all I would ask is that others
keep the above thoughts in mind as they pursue other schemes, whether they demand that modules know about
other modules or not.

Take care!

- les






More information about the Squeak-dev mailing list