Correcting C++ namespace shortcomings

The most visible function of the linker at language level is the separation of definitions from implementations. For instance, we usually put the definition of a class in a header file, and the implementation of its methods in a source file. We then include the header file in all source files in a project that need the definition of that class. The linker will resolve all calls to methods of the class in all source files.

A static library is a precompiled set of implementations. When the definitions in header files have been standardized, we may choose different libraries for the same header files. The linker will resolve the symbols against the first library that it finds on its path. The C++ namespace solves some issues with this last statement. Specifically, the linker will resolve symbols against the (first) library on its path that uses the same namespaces as our sources do. This allows different vendors supply static libraries for the same set of standardized header files.

When packaging libraries we have to write a substantial amount of code for internal use. We would like to hide the background work and only expose the portions that we intend the user of our library to have access to. Comments are of little help. A better solution is to equip namespaces with private and public sections.

Sometimes we need to extend an existing library. We would like to do so without modifying the library itself, just as one does with classes. It is therefore desirable to equip namespace construct with the same derivation mechanism as class construct enjoys. Derivation is also quite useful in the initial design of large libraries.

The using statement in C++ opens up a namespace without end. For instance, suppose libraries U and V provide different implementations for similarly named abstract data types. We would like to use U for some portions of our code, and V for the rest. That can easily happen when our module interacts with modules that have used one or the other library. Consequently, we need to be able to close U, before we open V, and vice versa.

The abstract programming language Z++ elegantly solves all of the above-mentioned shortcomings, and more. Thus, Z++ is a superset of C++ with corrections to C++.