Customising Box Behaviour

Introduction

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.

Defining Conditions in Boxes

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

call Condition in Box

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.

Creating modified box classes

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 folder. 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 (r.cooper@bbk.ac.uk) 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.

Box methods

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 (e.g.,
'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 folder.

initialise_object(Id, Class, Type)
Used to initialise the box. Type gives the initialisation level (one of session, subject, block and trial).

step_data(Id, Class)
Used to update the state of buffers, and to decay buffers.

step_box(Id, Class)
Used to update the state of other box types, especially processes.

dump_state(Id, Class)
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.