Go to the first, previous, next, last section, table of contents.


Units

A unit is the TOM equivalent of a library or program. Every separate library is a unit, and every program is a unit. A unit consists of a number of source files, each containing one or more classes or extensions. A unit can depend on other units, like in C, where the Motif library depends on the X11 library, and like every C program depends on the C standard library.

As an example, the following unit file defines a unit myprog. It depends on the standard environment unit tom (see section unit tom) and consists of a single source file file1 which contains a class named Hello and an extension of the OutputStream class. Since all TOM source files have the extension .t, the actual file of this unit will be called file1.t.

unit myprog

uses tom;

file "file1"
{
  class Hello;
  extension OutputStream (myprogExtension);
}

end;

A unit is defined by its unit file. Normally, the unit file is created by the interface generator gi (see section gi). For a unit myprog, the unit file will be myprog.u.

The TOM compiler uses the unit files to know where to look for definitions of a class. As a consequence, there is no need for TOM sources to contain #include, import, use or other manual dependency indications: If a TOM source uses a class Foo, the compiler will automatically read that class' definition.

Facts

Syntax

The syntax defined in this chapter is the syntax of unit files. Unit file syntax is different from (and in fact unrelated to) the TOM syntax presented elsewhere throughout this document.

unit_file:
          unit
        ;

unit:
          `unit' unit_name unit_decl_entry* `end' `;'
        ;

unit_name:
          identifier
        ;

unit_decl_entry:
          `uses' identifier_list `;'
        | unit_file_indication
          `{' (unit_plain_decl_entry `;')+ `}'
        | unit_decorated_decl_entry `;'
        ;

Each unit_decl_entry either declares the use of other units, defines the (partial) contents of a file or declares the existence of a class or extension.

unit_file_indication:
          `file' STRING_CST
        ;

The STRING_CST denotes the name of a file; such a filename excludes an extension; the default extension .t is always used.

unit_decorated_decl_entry:
          unit_plain_decl_entry [unit_file_indication]
        ;

A unit_decorated_decl_entry is a unit_plain_decl_entry optionally followed by an indication of the filename. If the filename is not provided, a suitable default is assumed. This is the name of the class for a class definition (the main extension thereof, really); it is the name of the extension for an extension definition.

unit_plain_decl_entry:
          `class' IDENTIFIER [unit_posing_decl]
        | `extension' class_name `(' IDENTIFIER `)'
          [unit_posing_decl]
        ;

An entry either defines a class, or it defines an extension of another class, which could reside in the current unit.

[Note: This syntax is not consistent. Instanceless classes and classless instances should be possible. An extension is nothing more than a class with a non-empty extension name. End note.]

unit_posing_decl:
          `posing' class_name
        ;

The class_name is the name of an existing class, see section Objects, classes and instances.

A unit_posing_decl declares that the definition of the enclosing class or extension declares a posing superclass. This information is necessary in the unit file, as the compiler deduces from the unit files which files need to be read to obtain the full declaration of a class, and for the full visible view of a class that is being posed, the posing subclasses must be read as well.


Go to the first, previous, next, last section, table of contents.