While the range of predefined box classes in COGENT is wide enough for many needs, some users may wish to override COGENT's internally defined methods or access procedures, substituting their own. This can be achieved by means of conditions defined in the boxes themselves. Currently only the Process and Buffer box classes permit definition of conditions.
Conditions are defined in boxes by means of the Condition Editor. User-defined conditions are accessible only inside the box in which they are defined, unless they are explicitly made accessible to another box by means of a read arrow, in which case they can be called from that box via the
built-in condition. This route may be used to give certain inferential capabilities to a buffer, for example, to draw deductive consequences from the buffer's contents. A Process can then access the buffer's local Conditions instead of having to perform the inferential computations locally.
From COGENT version 1.10.00, the box class hierarchy is defined as a set of Prolog module files, each of which defines the computational properties of one box subclass. These can be found in the .../oos/classes directory. Each class defines a number of methods, which are called at various points in the processing cycle, and which govern how boxes of that class should behave at that point in the processing cycle. New classes can be defined (for OOS) by creating a new class file and registering it in the hierarchy.pl file. There are dependencies between class definition files, as subclasses typically use conditions defined by their parent classes.
Note that at present, COGENT does not support the addition of new user-defined classes without recompilation of the main COGENT program, but we hope to remove this limitation at some point in the future. For now, if you want to try out a new box class defined this way, you will have to contact us (firstname.lastname@example.org) for assistance. If you do create a new subclass, we might be interested in including it in the standard COGENT distribution.
It is also possible to modify the way the existing classes work, by editing the class definition file to change the defined methods. This is not recommended as it will probably break the system unless you know what you are doing. It is preferable, at first, to develop a modified class by creating an instance of a standard box class, then overriding its internal methods by redefining them inside that box using the condition editor. In practice, this is only worthwhile for buffers.
In each of the methods described below, the argument Id will be instantiated as an integer identifier of the box, and Class will be instantiated as the COGENT class specifier (eg 'Buffer'/'Table'). Look at the standard class definition files to see how these can be used.
The first five methods are defined for all box classes:
process_box_content(Id, Path, Class)
Used to load the contents of the box. Path gives the pathname of the box's definition directory.
initialise_object(Id, Class, Type)
Used to initialise the box. Type gives the initialisation level (one of session, subject, block and trial).
Used to update the state of buffers, and to decay buffers.
Used to update the state of other box types, especially processes.
Used to save the state of each box at the end of each cycle.
The last method is defined only for buffers:
match(Element, Id, Class)
This is the method which governs the application of Buffer access property settings. Unlike the others methods, this one should re-satisfy for each accessible buffer element, in an order governed by the access property setting.