| |
| |
| |
| |
(I'm sorry of possible bugs, but I converted this material from hardcopy on paper using OCR program)
Structured Symbolic Name Spaces in Smalltalk
Augustin Mrazik, augustin@artinapples.sk
(does not work – for current info see http://www.whitestein.com )
ArtinAppleS,spol. s r.o., Kremelska 13, 845 03 Bratislava, Slovakia
tel.: (+42 7) 362 889, 365 233 fax: (+42 7) 777 779
Introduction
The standard Objectworks\Smalltalk programming environment supports symbolic identification of objects in one global namespace - in the Smalltalk system dictionary. This means that each global variable in the system has its unique name which is used for symbolic identification of the particular object in the source code (e.g. in expressions or methods). Most important global variables are classes desfining the behavior of objects.
In a development dealing with modelling of real systems polymorphic symbolic identitication is often needed. This means that it should be possible to use the same name for
different classes or other global variables. Let us mention class Module as an example which would mean totaly different things for a programmer, for a computer technician and for a civil engineer or an architect.
This issue becomes inevitable if we start to work with a object-oriented database management system in the Smalltalk environment. Polymorphism of classes becomes necessary in the moment we start to think about storing classes in the database since after restoring them into the running Smalltalk image a missmatch with the current symbolic identification of the present classes could occur. For example you might have the class Module already in your image with the meaning of a program module (e.g. in a CASE system) and you might attempt to load the class Module representing a part of the computer hardware from the database for hardware configuration system. The last class could get bound to the #Module symbol in the Smalltalk system dictionary and the other class could remain in the system as unbound class with full functionality, however, it could not be accessed anymore at the symbolical level in the source code.
The Objectworks\Smalltalk system partially includes support for diverse name spaces environments. However, first the environments and polymorphic class identification have to be designed on a conceptual level and just then implemented in the system.
Concept of the Environments
Objects which have to be identified in the source code of methods or message sends by their names are included in Smalltalk which is a sole instance of SystemDictionary. Such objects may be identified simply by stating their name as primary in a Smalltalk statement. The code is compiled in the Smalitalk environment and if such a primary is found it is bound to the corresponding object as receiver of the rest of the message send. In this way Smalltalk as instance of SystemDictionary represents the sole symbolic name space in the Smalltalk OOPS. In the following text the symbolic name space will be called simply environment to make the text more clear.
To support polymorphic symbolical identification several environments will be needed. The same name may be located concurrently in several environments and point to diverse objects.
However, symbolic navigation between these environments is needed. The implementation of such a navigation includes following issues:
Since the environment has first to be symbolicaly identified to gain access to its global variables, it has to be a global variable in another environment. Obviously, Smalltalk will be the first environment from which the navigation begins. From Smalltalk some of the existing
environments may be seen. From these environments other environments may be seen, etc. This means that environments represent nodes in a graph where symbolic identifications from one environment to another one represent branches.
However, the symbolic identification should be unambiguous although it will be Polymorphic. This is why we should avoid cycles in the environment graph. Cycles in the graph could cause also other problems in the implementation, e.g. unability to use recursive algorithms. This is why in general the environments build a directed acyclic graph.
Let us call the parcial ordering relation which occurs between the two environments to be inheritance. The sub-environments inherits from its super-environments.
Not only that 'inheritance' is the standard term for the parcial ordering relation in the lattice theory but the feature of inheritance in the meaning of object-orientation is associated with this relation. This means that all associations of the super-environment are valid also in its sub-environments unless they are locally redefined in the sub-environment.
In our example shown on Fig. 1 (ommited). environment A inherits from Smalltalk and environment D inhetits from both environments A and B while environments C and D are mutually uncomparable, i.e. no inheritance relation exists between these two environments. If an object is included in the A environment, it is known also in C and D. All objects from Smalltalk are known in all environments unless they include another object under a used symbol.
Inheritance Links
A super-environment includes all its sub-enviroments as associations under their names. The sub-environment includes all its super-environments under the symbol #Super. In this way cycles may be avoided in the environment lattice if a special method will be used for connecting environemnts, i.e. defining the inheritance relation between two environments. Further all environments know Smalltalk - the root environment. Since they all inherit from Smalltalk all global variables defined in it, it is not necessary to define a special global variable pointing to root in each environment.
The inheritance links to the super-environments are used in the lookup for a potentially inherited global variable. The Super variable of each environment keeps all the super-environments of the particular environment in historical order, i.e. in the order in which it became sub-environment of them. In the inheritance lookup two approaches may be used:
- historical - the lookup is performed from the first to the last super-environment, i.e. the historical principle is used (the older super-environment superseeds the more current one),
- current - the more current super-environment is looked for the symbol first.
Syntax
Global objects of an environment (local or inherited) may be referenced by their symbol used in the source code, e.g.
John goHome
if the #John -> aMan association exists in the particular environment or one of its super-environments.
If an object has to be referenced from another environment (i.e. which is not on the inheritance link) it has to be referenced:
We know already that each environment knows its super-environments. We have also shown that each environment knows also Smalltalk as the root environment.
For the identification of global objects in another environment a "pathname" of symbols is used. The symbols are separated by blanks, i.e. the final identification is a sequence of message sends:
Smalltalk Tasks MyTask
or
Super Super Peter.
Implementation
To implement the structured environments either a subclass of the SystemDictionary has to be defined and implemented with corresponding features or the SystemDictionary class has to be redefined. Since also Smalltalk has to be able to interpret the "pathnames" and other features correctly, implementation has to be done directly in SystemDictionary and/or in its subclass.
For the implementation of the above mentioned features following methods has to be redefined:
These methods are not all which have to redefined in the Smalltalk system to achieve full functionality of structured environments. Particularly changes have to be done in the behavior classes, some user interface classes etc. But full description of all changes exceeds the
frame of this paper.
System Organization and Classes
The most important task of the SystemDictionary is to Provide organization for the most important global objects in the Smalltalk system - for the classes. This importance becomes even more crutial in the structured environments which is first of all a framework for class polymorphism.
In Smalltalk the classes have the instance variable 'name'which hold the name of the class. Each corretly defined class is included in Smalltalk under this name.
In a framework with several environments the class should know its motherenvironment'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 tfiem in its mother environment even if this compilation is requested from another environment. If the syntax is not correct in the mother environment, simply the compilation error occurs.
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 the SystemBrowser). 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. In all other cases the class has to answer its full "pathname" from Smalltalk.
Class Migration
We have shown that classes are in some sense fixed to their mother environment. We might need to change the mother environment, i.e. to migrate the class between environments for some reason. In this case not only the mother environment of the class and svstem organization of both environments has to be updated, but the class has to be recompiled in the new environment. Of course, the class must either have been already included in the new mother environment under its name, or it has to be put there at the moment of migration.
User Interface for Structure Environments
For full utilization of the structured environments for applications the user interface for navigation between environments and changes to existing browsers have to be done.
For environment access the EnvironmentHierarchyBrowser is used. This is an extended Dictionaryinspector which show sub-environments in the left subview (only sub-environments, not all global variable of the environment) and the contents of the target environment of the right hand side.
For expression evaluation the Workspace is extended by the environment in which the text is compiled. Of course, the most important tool which has to be changed to utilize the structured environments, is the SystemBrowser.