GEOS SDK TechDocs
|
| 
3 The Library Entry Point
| 
5 Header Files
Writing routines for a library is very much like writing them for an application. Simply export the routine in the .gp file and any geode which uses the library will be able to call the routine.
It is important when writing routines for export to document the routines exhaustively. Remember that the library will probably be used by other programmers; they will rely on the routines to behave exactly as specified. Exported routines should also minimize side effects; for example, it is a bad idea for a library routine to change the working directory without changing it back, unless that is the routine's main purpose.
Most libraries will have a number of routines which are not for export, but are used by routines that are exported. These are simply written normally, and are not exported in the
.gp
or declared in the header file. Remember that programmers will not see these routines; their side effects should thus be fully documented with the exported routines which call them.
Some libraries will declare classes of objects. In this case, the library should specify in the
.gp
file that it uses whichever library defines the superclass of the object. For example, if a library defines a subclass of
GenClass
, it should specify that it uses the
UI
library. It should then export the new class.
Some libraries will declare classes that are not intended to be used by clients. For example, the Impex library declares
ImportExportClass
. This class is never instantiated; it contains code and instance data that are used by its subclasses (
ImportControlClass
and
ExportControlClass
). Such "hidden" classes need not be exported. However, the classes must be fully declared in the header files so the subclasses can be defined accurately and consistently.
GEOS SDK TechDocs
|
| 3 The Library Entry Point
| 5 Header Files