Previous: Why Object Oriented programming?
Up: Object Classes
Next: Automatic messages
Previous Page: Why Object Oriented programming?
Next Page: Automatic messages
DSPACK implements these concepts in the following manner:
A class (or a set of classes) for each object may be set after the object has been defined. All methods required for the class are kept in a Class Driver - a program with a single entry point which is called when the program sends a message to the object of that class. Usually the program must be linked with the user's code and DSPACK should be informed with a ds_install call (but there are exceptions where this is not required).
Together with the class of an object the user may specify object type - this is a small integer number which is never used by DSPACK, but is passed together with the message - allowing the driver to handle 'sub-classes' of it's own class.
The driver may respond to the message if it contains a method for it or it can ignore it. If the message is ignored by the driver (or if it 'pretends' to ignore it - see below) then the next class up of the 'genealogical tree' of the object is called and so on - until the message is handled.
In some cases it may be convenient for the driver to perform some action in response to the message but still allow inherited methods to work - the driver may 'pretend' not to handle the message. (An example: DSPACK contains a standard method to show the contents of an object - in response to a SHOW message. If the object belongs to a class, then the class driver is called first and standard SHOW is performed only if the driver does not respond - this allows the driver to show extra information about the object and then force the standard method to be used for the contents display)