An object in CLIPS is defined to be a symbol, a string, a floatingpoint or integer number, a multifield value, an externaladdress or an instance of a userdefined class. Section 2.3.1 explains how to instances of userdefined classes. Objects are described in two basic parts: and . A class is a template for common properties and behavior of objects which are instances of that class. Some examples of objects and their classes are:
Object (Printed Representation) Class
RollsRoyce SYMBOL
"RollsRoyce" STRING
8.0 FLOAT
8 INTEGER
(8.0 RollsRoyce 8 [RollsRoyce]) MULTIFIELD
<Pointer- 00CF61AB> EXTERNALADDRESS
[RollsRoyce] CAR (a userdefined class)
Objects in CLIPS are split into two important categories: primitive types and instances of classes. These two types of objects differ in the way they are referenced, created and deleted as well as how their properties are specified.
P objects are referenced simply by giving their value, and they are created and deleted implicitly by CLIPS as they are needed. Primitive type objects have no names or slots, and their classes are predefined by CLIPS. The behavior of primitive type objects is like that of instances of userdefined classes, however, in that you can define messagehandlers and attach them to the primitive type classes. It is anticipated that primitive types will not be used often in an objectoriented programming (OOP) context; the main reason classes are provided for them is for use in generic functions. Generic functions use the classes of their arguments to determine which methods to execute; sections 2.3.2, 2.5.2.2 and 8 give more detail.
An instance of a userdefined class is referenced by name or address, and they are created and deleted explicitly via messages and special functions. The of an instance of a userdefined class are expressed by a set of slots, which the object obtains from its class. As previously defined, slots are named single field or multifield values. For example, the object RollsRoyce is an instance of the class CAR. One of the slots in class CAR might be ìpriceî, and the RollsRoyce objectís value for this slot might be $75,000.00. The behavior of an object is specified in terms of procedural code called messagehandlers, which are attached to the objectís class. Messagehandlers and manipulation of objects are described in Section 2.5.2.3. All instances of a userdefined class have the same set of slots, but each instance may have different values for those slots. However, two instances which have the same set of slots do not necessarily belong to the same class, since two different classes can have identical sets of slots.
The primary difference between object slots and template (or nonordered) facts is the notion of inheritance. Inheritance allows the properties and behavior of a class to be described in terms of other classes. COOL supports inheritance: a class may directly inherit slots and messagehandlers from more than one class. Since inheritance is only useful for slots and messagehandlers, it is often not meaningful to inherit from one of the primitive type classes, such as MULTIFIELD or NUMBER. This is because these classes cannot have slots and usually do not have messagehandlers.
Further discussion on these topics can be found in Section 2.6,
and a comprehensive description of the CLIPS ObjectOriented Language
(COOL) can be found in Section 9.
2.4.2.1 Initial Objects