Namespaces & Private Classes

Introduction & motivation
Using namespaces
Programming considerations
Private classes
ST/X extensions
Hints

Introduction & motivation

ST/X provides multiple namespaces and private classes to allow better structuring of big projects and to avoid name conflicts. These conflicts also often occur, when alien classes are loaded (filedIn) into the system.
A namespace logically represents a dictionary referring to classes; Smalltalk itself plays the role of a default namespace. (although, the actual implementation is a bit different, due to the way global variables are handled in statically compiled code).
When a class is compiled, references to other classes are resolved first in the classes own namespace, then in the default namespace (Smalltalk).

The ST/X implementation of namespaces and private classes does not completely hide those classes - if required, access is still possible from the outside (and sometimes very useful); however, this access is not possible by accident - an explicit language construct is required to access those hidden classes.
Explicit access to a class from a particular namespace is possible either by using a namespace prefix (which is an ST/X language extension), or by accessing the namespace via "at:" messages (which can be made portable, by adding an implemenation for this message to the other smalltalk dialect).

A namespace-classes sourcecode is backward compatible with systems which do not know about namespaces - i.e. it is possible to fileOut a class from ST/X which is located in some namespace, and load it into VisualWorks, for example. However, the namespace information is lost in the target system - the class will end up as a global class in VW.
This is possible, since the namespace information is contained within comments, which are ignored by other systems.

Notice, that the above is not completely true:
if an explicit namespace prefix is used, other systems may not be able to load the class.
Therefore, if backward portability is required, do not use explicit references to classes in other namespaces (use #at: accesses, which can be simulated in the other system using poolDictionaries, globals or classVariables).

Using namespaces

The ST/X browser has been modified to know about namespaces and has an additional namespace field, to allow setting a filter on which namespace-classes are to be shown.
The default setting is "* all *" which turns off any filtering and shows all classes. In this case, class names are prefixed with their namespace in the class selection view, unless the class is global (i.e. in the Smalltalk namespace).
Thus, in the browser, classes can be added to or modified in any namespace.

A different mechanism is used when classes are loaded from external files (i.e. filedIn); in this case, the current project provides a default namespace into which new classes are installed (of course, by default, the default namespace is Smalltalk - thus loaded classes are global by default).
To load a bunch of classes into a separate namespace, create a new project (i.e. open a projectView), activate it and set its default namespace (in the project views popupMenu). Then fileIn the classes.

Programming considerations

Globals are resolved at compilation time - that means, that programmatic changes in a namespace do not automatically affect code which was already compiled.
However, the browser recompiles all methods which refer to a global, when a new class is added or removed from a namespace (since the variable-name may now refer to another global or namespace variable ...)

Thus, if your program adds classes to a namespace, make certain that relevant methods are recompiled
(i.e. use "Metaclass recompileMethodsAccessingGlobal:aGlobalKey").
We repeat: this is only required if globals are added by the program
- the browser does this automatically for you.

Private classes

These are much like classes within a namespace - actually, the same mechanisms are used, and a class (the owning class) plays the role of a namespace for its private classes.
Although possible, we do not recommend a deep nesting of private classes: experience shows, that it complicates things and leads to unreadable and hard to maintain code.

Like with regular namespaces, access from outside is not strictly impossible - if prefixed with the owners class name, private classes can be accessed.
However, we do not recommend this - if there is a need to access a private class from the outside, make it public, or place it in a true namespace.

ST/X extensions

Creation of a namespace:
Namespace name:'nameOfNameSpace'
Fileout format namespace information (at the top of the source file):
"{ NameSpace: nameOfNameSpace }" notice, that this is a comment to other smalltalk systems.
Namespace prefix (explicit reference to a class in another namespace):
nameSpace::className (this is an ST/X extension, which is NOT compatible with other smalltalk systems).
For compatibility, the ST/X parser also recognizes the VW5i nameSpace syntax (using a period '.' as separator), if the corresponding flag is turned on in the launcher's settings-compilation-dialog.
backward syntax compatible access (can be used in other systems as well):
nameSpace at:#className
definition of a private class:
superClass subclass:#className instanceVariableNames:'...' classVariableNames:'...' poolDictionaries:'' privateIn:owningClass as a special case, a class may define a private class as a subclass of itself (see the WindowEvent class hierarchy for a concrete example).

Hints

We do not recommend nesting namespaces; first it can make the code rather unreadable, second, it is not supported very much by the browser (i.e. the filter is not hierarchical), and finally: it has not used much in the past and is therefore not tested in depth.

We recommend a flat hierarchy, using a single namespace per application.

<cg at exept.de>

Doc $Revision: 1.16 $ $Date: 2021/03/13 18:24:51 $