The MICA type system

MICA's type system -- the way that different objects are represented -- is similar to many object-oriented systems. As previously discussed, objects have a type; and types can inherit from one another. Each type typically has certain slots associated with it. Each slot can have a list of values.

The current implementation of MICA is simple. Firstly, slots can currently only have values that are Strings. Ideally, it would be useful to have slots that can have other types, e.g. ints, doubles, and so on[2]. Secondly, although it would be typical for a particular type to have particular slots, this is not enforced in any way. For example, consider the sharedPadLine mob in Figure 4.1. Although we expect that a sharedPadLine would have the six slots shown, it is perfectly possible to construct a sharedPadLine that has no oldX slot.

MICA supports multiple inheritance: a given type can have several superclasses. Unlike languages like Smalltalk where each object can have multiple types, however, a single mob can only have one type; although any type may have several supertypes.

To simplify management, there is a universal supertype, called "mob". Every type is assumed to inherit from "mob". When an object is created on the blackboard, the blackboard also creates two slots, each with a single value: creationTime, the time at which the agent was created; and creator, the agent that created a particular mob.

It is also important to note that the registration system heeds inheritance; in other words, if an agent registers for a mob of a given type, the agent is informed if any subtype is also written to the blackboard. This is an extremely important feature. For example, it makes writing a "debugger" agent that displays everything on the blackboard very easy. All the agent need do is register for any mobs that are of type "mob" and it will be informed of any mob written to the blackboard. Similarly, say some kind of complex agent has a whole family of mob types that it has to listen to. If all the mobs inherit from a common type, then it is easy to register for a whole family of mobs in a single go.

A further use of the type hierarchy is as a way of specifying transience. Although individual mobs can be specified as transient by the makeTransient method, it is often the case that all mobs of a particular type will be transient. If a mob type is specified as transient then all mobs of that type will be automaticlly made transient by the blackboard. This feature also obeys type inheritance, so that if some type is declared transient, all type inheriting from it will also be transient.



[2] One particularly useful type would be a reference to another Mob. However, similar functionality can be achieved by using the name of the mob and storing it in a slot as a string, and then using the readMob() method to find the useful information.