Key usage within Collections

The classes in the Database family (called "Databases" for short) and in the Map family (called "Maps" for short) are templates over " <S,T>": class S is called the key class, and class T is called the data class.

For the sake of performance, key class objects are owned (or pointed at) by naked pointers (not allowed in most of Polaris) which means they do not have to be derived from Listable. However, data objects are owned (or referred to) using the standard Wrapper structure, which introduces the standard limitations:

• Items owned or referred to by a Collection must be derived from Listable.

• Items referred to by a Collection must be owned by another Collection (specifically, by a List, Element, or as a data item of a Database or Map... being a key item for another Collection is NOT enough).

Items in both Databases and Maps can be found, grabbed, or deleted by key. If a key object is owned, deleting the associated Database or Map entry deletes the associated key object (which might be a clone... see below). If a data object is owned (or referred to), deleting the associated Database or Map entry deletes the associated object (or associated reference to the object).

Unfortunately, the KeyIterator

• does not support many potential changes to the underlying Database or Map during iteration and
• iterates over objects in an arbitrary order... so it is often used to build a (possibly sorted) List or RefList of objects for later processing.

• Properties
• Key Comparison
• Why is external meaning important?