www.delorie.com/gnu/docs/smalltalk/gst_13.html

search

	Buy GNU books!

GNU Smalltalk User's Guide

2.2.4 Implementation

A superclass of SystemDictionary called RootNamespace has to be defined and many of the features of Smalltalk-80 SystemDictionaries will be hosted by that class. Namespace and SystemDictionary will in turn become subclasses of RootNamespace. One could wonder why is RootNamespace superior to Namespace in the hierarchy: the answer is that it is more convenient because root namespaces are more similar to Dictionaries, not having to handle the burden of lookup into super-environments.

To handle inheritance, the following methods have to be defined or redefined in Namespace (not in RootNamespace):

Accessors like #at:ifAbsent: and #includesKey:

Inheritance has to be implemented.

Enumerators like #do: and #keys

This should return all the objects in the namespace, including those which are inherited.

For programs to be able to process correctly the "pathnames" and the accessors, this feature must be implemented directly in RootNamespace; it is easily handled through the standard doesNotUnderstand: message for trapping message sends that the virtual machine could not resolve. RootNamespace will also implement a new set of methods that allow one to navigate through the namespace hierarchy; these parallel those found in Behavior for the class hierarchy.

The most important task of the Namespace class is to provide organization for the most important global objects in the Smalltalk system--for the classes. This importance becomes even more crucial in the structured environments which is first of all a framework for class polymorphism.

In Smalltalk the classes have the instance variable name which holds the name of the class. Each defined class is included in Smalltalk under this name. In a framework with several environments the class should know the environment in which it has been created and compiled. This is a new variable of Class which has to be defined and properly set in relevant methods. In the mother environment the class should be included under its name.

Of course, any class (just like any other object) may be included concurrently in several environments, even under different symbols in the same or in diverse environments. We can consider this 'alias names' of the particular class or global variable. However, classes may be referenced under the other names or in other environments as their mother environment e.g. for the purpose of intance creation or messages to he class (class methods), but they cannot be compiled in other environment. If a class compiles its methods it always compiles them in its mother environment even if this compilation is requested from another environment. If the syntax is not correct in the mother environment, a compilation error simply occurs.

An important issue is also the name of the class answered by the class for the purpose of its identification in diverse tools (e.g. in a browser). This has to be change to reflect the environment in which it is shown, i.e. the method `nameIn: environment' has to be implemented and used on proper places.

These methods are not all which have to redefined in the Smalltalk system to achieve full functionality of structured environments. In particular, changes have to be made to the behavior classes, to the user interface, to the compiler, to a few classes supporting persistance. An interesting point that could not be noticed is that the environment is easier to use if evaluations (doits) are parsed as if UndefinedObject's mother environment was the current namespace.