A Proposal for Project Layers

Augustin Mrazik amr at whitestein.com
Tue Oct 19 17:22:36 UTC 1999


Hello Dan,

I've got an idea which might simplify the namespaces more and even make all naming issues more "object oriented". It would be even much much more (in the blue plane direction ?). (You should know that we are working on a distributed system in Squeak where naming issues play a significant role - this is why I returned to namespace problems after 7 years and we've been implementing them in Squeak. We will publish more about this project later this year.)

The idea:

The only mechanism for naming, i.e. giving names to objects and using these names for resolving in compile time (or run-time) would be _class_. Names assigned to objects at a class level are visible only within classes ñ let us call it _notions_ (in normal life, a notion is an object well-known under a certain name). However, a class could contain not only methods, but also other classes ñ just like main class and inner classes in Simula and Java.

Subclass of a main class would inherit all classes, methods and notions from its superclass. Within such a main class, all inherited classes may be sub-classed (since they are visible here), methods may be added and redefined as usual and notions may be added and redefined just like methods (in this way, also our hierarchical namespaces work). Such a main class is basically a development environment for applications, however, with the possibility to make several variants of  the same application. It would be basically a kind of _project_, where a project would inherit from its super-project, however, a super-project could have several
independent subprojects, even with contradicting functionality.

At this level of 2 of ìinner classesî, the system would build a world which could be specialized in a hierarchy. However, any inner class could also include classes and hence be another such world in another dimension.

The whole system would be Smalltalk, which would not be aSystemDictionary, but again a class, including all top-level worlds. Wouldnít it be nice, that the system would be a kind of behavior instead a kind of dictionary ?

The question arises what would be instances of a main class. The answer is simple: it is just the same as today, a concrete instance of its class, the object which is able to understand and use anything defined in its class. But now, it would understand and use not only methods, but also classes. Simply, an instance of a main class is _the application_, a concrete use of all classes and methods defined in its (main) class, seeing all notions (ìglobal variablesî). Each application would be able to have its own variables ñ defined as instance variables in its class, and it would have its ìglobalî behavior defined in methods of its class. In this
way, _several applications_  could coexist in the system concurrently, each in a different state. If an application would be a notion on its class level, it could be referred from other applications. Instances of main classes would be hence instantiations of the knowledge defined in their class.

The implementation of namespaces in this way (in comparison to the current implementation which we have sent you) seems to be even much more simple. Simply changing a little bit the Behavior and its subclasses and no need for another classes implementing inheritance. Class pools are simply ìglobalsî ñ no (or almost no) changes to the compiler. Ö

And image segments: excellent with such classes;-). Any main class may be swapped out or in.

Augustin





More information about the Squeak-dev mailing list