Programming guide to Unibase

6 : Documentation and modules

The various global defined objects in the language can all contain text for the documentation. These texts are collected during compilation and from it some documents are created for programmers to use these objects. A module in the language has a heading that can contain version data, the name of the original creator and the current maintainer. Also a string is reserved for an URL to the place where more recent information about the module and possible bug fixes can be obtained. In this way people can get in touch with the current maintainer. This will be increasingly useful when more people join to write modules to the language.

Modules can contain several types of objects:

	Additional types and operators to the language.
	New table definitions.
	Global variables.
	New routines for the language.
	Links to existing C libraries.
	System routines with normal ANSI-C code in them for interfaces to those libraries.

So a module can grow from a set of routines added to a single table towards a major update of the whole language. In fact all the types and standard routines of the language are now already stored in modules. The first line of a new program should include the module "standard" so the language will know the standard types and functions. Without these types, operations and functions the language is only an empty shell.

Using Platform dependent libraries

There can be modules that will only run in combination with certain C libraries but that should be stated firmly by the writer and maintainer of these modules. Normal use of the language should be as platform independent as possible. And even then the use of totally normal libraries is highly advisable. If people want to write a module for the use of SVGA-lib then they should beware that there should also be a similar version for the use on a Microsoft platform and one under X-windows.

Internet technology

I prefer the use of CGI because it is multi-user by default and it is easier to maintain on multiple platforms. There could be future developments for Java-applets with more client-side functionality. This is to my opinion a better line of development than to create a whole bunch of different modules for all kinds of systems. The Java-applets should open a socket to the same application and get continues data from it instead of the rigid CGI programming. This can lead to a set of small Java-applets that greatly enhance the options to write user interfaces.