SUMMARY: MODULE | CLASS | TYPE | PROC | VAR | CONST | DETAIL: TYPE | PROC | VAR | CONST

# libadt

Some words on the module hierarchy layout of ADT:

- All modules of this library implementing abstract data types use the prefix ``ADT:`'. Test modules are not considered part of the library. They reside in the top-level namespace, have ``Test`' as prefix, and are not installed together with the library modules.

- New datatypes are defined in ``ADT:*`' modules.

- Extensions of datatypes or implementations of abstract types should also use ``ADT:*`' names. This avoids a deeply nested namespace for families of datatypes structured through inheritance.

- Specialized implementations of an existing datatype that do not add any relevant functionality use the name of the more general implementation as prefix. Example:

  ADT:Dictionary | The general purpose implementation of a dictionary. It maps objects to object references.
  ADT:Dictionary:IntValue | A version of a dictionary that maps objects to LONGINT values, instead of object references. The same could be achieved using the ``ADT:Dictionary`' implementation, at the cost of wrapping all integer values into objects. The user is encouraged to give such modules a more sensible name on import, for example ``IMPORT Dictionary := ADT:Dictionary:IntValue`'.

  The documentation of the general implementation should provide links to the specialized versions.

- Modules providing services or algorithms for data types, but do not define a new data type themselves, use the name of the base module as prefix. For example, a serialization implementation is in module ADT:Object:Storage, because it implements the abstract rider interface defined in ADT:Storable.

It is expected that the ``ADT:*`' namespace will be quite flat and broad.

### Import List