Keys are homogeneous
The key in the key-value pair can be any data type derived from MCollectible. Whatever type you choose, every key you add to the dictionary must be an instance of the same type. In other words, keys are homogeneous--they are all instances of the same class. For keys, you can use numerical data, such as integer and long, or text (subclasses of TText). While you can use other types for keys, it's best to use simple types for fast indexing to achieve optimal performance.
Indexing operations invoke the IsEqual member function for the class of object acting as the key. For example, if the keys are of type text, then the index function calls TText::IsEqual.
For the fastest comparisons use the numerical types integer and long. Although it is possible to use a key that is a complex sound or graphic data type, this kind of indexing is very time consuming and is not an optimal design choice.
Values are heterogeneous
The value associated with the key can be any data type derived from MCollectible. The difference between keys and values is that values need not all have the same data type. The term heterogeneous refers to the idea that a collection, such as a dictionary, can contain objects that are instances of several different classes. The benefit of supporting heterogeneous types for values is that you can store all related data for a given program or project in a single disk dictionary, even if the component data consists of many different kinds of objects.
For example, heterogeneous values are useful when working with the CommonPoint document framework. Portions of a compound document need to be stored together on disk, yet they contain several different objects of different data types. A typical compound document is shown in Figure 24, where the embedded objects include a graphic (hands shaking), text, and a table. These instances are stored together in the same disk dictionary, indexed by the identification field of each instance, which is of type TLong. This index value is generated behind the scenes by the default index manager.
One possible mapping for the key-value pairs of a disk dictionary used to implement the document in the figure is shown in the following table.
| Key | Value | |
| 147 | graphic | |
| 319 | text | |
| 652 | table |
The persistent storage subsystem allows you to easily store these different component types into a flexible disk-based file system very similar to a database. You can retrieve the components very quickly using the appropriate key.
Click the icon to mail questions or corrections about this material to Taligent personnel.