Typedef

A type definition (typedef) is a part that is used as a model of format. You use the typedef mechanism for these reasons:

Often, typedefs identify an abstract grouping. You can declare a record part named address, for example, and divide the information into streetAddress1, streetAddress2, and city. If a personnel record includes the structure items workAddress and homeAddress, each of those structure items can point to the format of the record part named address. This use of typedef ensures that the address formats are the same.

Within the set of rules described in this page, you may point to the format of a part either when you declare another part or when you declare a variable.

When you declare a part, you are not required to use a part as a typedef, but you may want to do so, as in the examples that are shown later. Also, you are not required to use a typedef when you declare a variable that has the characteristics of a data item; instead, you can specify all characteristics of the variable, without reference to a part.

A typedef is always in effect when you declare a variable that is more complex than a data item. For instance, if you declare a variable named myRecord and point to the format of a part named myRecordPart, EGL models the declared variable on that part. If you point instead to the format of a part named myRecordPart02, the variable is called myRecord but has all characteristics of the part named myRecordPart02.

The table and sections that follow give details on typedefs in different contexts.

Entry that points to a typedef	Type of part to which the typedef can refer
function parameter or other function variable	a record part or dataItem part
program parameter	dataItem part, form part, record part
program variable (non-parameter)	dataItem part, record part
structure item	dataItem part, record part

DataItem part as a typedef

You can use a dataItem part as a typedef in the following situations:

When declaring a variable or parameter
When declaring a structure item, which is a subunit of a record part, form part, or dataTable part

These rules apply:

If a structure item is a parent to other structure items that are listed in the same declaration, the structure item can point only to the format of a dataItem part, as in this example:

  DataItem myPart CHAR(20) end

  Record myRecordPart type basicRecord
    10 mySI myPart; // myPart acts as a typedef
      20 a  CHAR(10);
      20 b  CHAR(10);
  end

The previous record part is equivalent to this declaration:

  Record myRecordPart type basicRecord
    10 mySI CHAR(20);
      20 a CHAR(10);
      20 b CHAR(10);
  end

You cannot use a dataItem part as a typedef and also specify the length or primitive type of the entity that is pointing to the typedef, as in this example:

  DataItem myPart HEX(20) end

  // NOT valid because mySI has a primitive type
  // and points to the format of a part (to myPart, in this case)
  Record myRecordPart type basicRecord
    10 mySI CHAR(20) myPart;
  end

A variable declaration that does not refer to a record part either points to the format of a dataItem part or has primitive characteristics. (A program parameter can refer to a form part, too.) A dataItem part, however, cannot point to the format of another dataItem part or to any other part.
An SQL record part can use only the following types of parts as typedefs:
- Another SQL record part
- A dataItem part

Record part as a typedef

You can use a record part as a typedef in the following situations:

When declaring a structure item
When declaring a variable (including a parameter), in which case the variable reflects the typedef in these ways:
- Format
- Record type (for example, indexedRecord or serialRecord)
- Property values (for example, value of the file property)

When you declare a structure item that points to the format of another part, you specify whether the typedef adds a level of hierarchy, as illustrated later.

These rules apply:

A record part can be a typedef when you use a structure item to facilitate reuse--
```
  Record address type basicRecord
    10 streetAddress1 CHAR(30);
    10 streetAddress2 CHAR(30);
    10 city CHAR(20);
  end

  Record record1 type serialRecord
  {
    fileName = myFile
  }
    10 person CHAR(30);
    10 homeAddress address;
  end
```
The second record part is equivalent to this declaration--
```
  Record record1 type serialRecord
    { fileName = myFile }
    10 person CHAR(30);
    10 homeAddress;
      20 streetAddress1 CHAR(30);
      20 streetAddress2 CHAR(30);
      20 city CHAR(20);
  end
```
If a structure item uses the previous syntax to point to the format of a structure part, EGL adds a hierarchical level to the structure part that includes the structure item. For this reason, the internal structure in the previous example has a structure-item hierarchy, with person at a different level from streetAddress1.

In some cases, you prefer a flat arrangement in the structure; and an SQL record that is an I/O object for relational-database access must have such an arrangement--

In the previous example, if you substitute the word embed for a record part's structure item name (in this case, homeAddress) and follow that word with the name of the record part that acts as a typedef (in this case, address), the part declarations look like this:
```
  Record address type basicRecord
    10 streetAddress1 CHAR(30);
    10 streetAddress2 CHAR(30);
    10 city CHAR(20);
  end

  Record record1 type serialRecord
  {
    fileName = myFile
  }
    10 person CHAR(30);
    10 embed address;
  end
```
The internal structure of the record part is now flat:
```
  Record record1 type serialRecord
  {
    fileName = myFile
  }
    10 person CHAR(30);
    10 streetAddress1 CHAR(30);
    10 streetAddress2 CHAR(30);
    10 city CHAR(20);
  end
```
The only reason to use the word embed in place of a structure item name is to avoid adding a level of hierarchy. A structure item identified by the word embed has these restrictions:
- Can point to the format of a record part, but not to a dataItem part
- Cannot specify an array or include a primitive-type specification

Next, consider the case in which a record part is a typedef when you are declaring identical structures in two records--

  Record common type serialRecord
  {
    fileName = mySerialFile
  }
    10 a BIN(10);
    10 b CHAR(10);
  end

  Record recordA type indexedRecord
  {
    fileName = myFile,
    keyItem = a
  }
    embed common; // accepts the structure of common, 
                  // not the properties
  end

  Record recordB type relativeRecord
  {
    fileName = myOtherFile,
    keyItem = a
  }
    embed common;
  end

The last two record parts are equivalent to these declarations--

  Record recordA type indexedRecord
  {
    fileName = myFile,
    keyItem = a
  }
    10 a BIN(10);
    10 b CHAR(10);
  end

  Record recordB type relativeRecord
  {
    fileName = myOtherFile,
    keyItem = a
  }
    10 a BIN(10);
    10 b CHAR(10);
  end

You can use a record part multiple times as a typedef when declaring a series of structure items. This reuse makes sense, for example, if you are declaring a personnel record part that includes a home address and a work address. A basic record could provide the same format in two locations in the structure:

  Record address type basicRecord
    10 streetAddress1 CHAR(30);
    10 streetAddress2 CHAR(30);
    10 city CHAR(20);
  end

  Record record1 type serialRecord
  {
    fileName = myFile
  }
    10 person CHAR(30);
    10 homeAddress address;
    10 workAddress address;
  end

The record part is equivalent to this declaration:

  Record record1 type serialRecord
  {
    fileName=myFile
  }
    10 person CHAR(30);
    10 homeAddress;
      20 streetAddress1 CHAR(30);
      20 streetAddress2 CHAR(30);
      20 city CHAR(20);
    10 workAddress;
      20 streetAddress1 CHAR(30);
      20 streetAddress2 CHAR(30);
      20 city CHAR(20);
  end

You cannot use a record part as a typedef and also specify the length or primitive type of the entity that is pointing to the typedef, as in this example:

  Record myTypedef type basicRecord
    10 next01 HEX(20);
    10 next02 HEX(20);
  end

  // not valid because myFirst has a
  // primitive type and points to the format of a part
  Record myStruct02 type serialRecord
  {
    fileName = myFile
  }
    10 myFirst HEX(40) myTypedef;
  end

Consider the following case, however:

  Record myTypedef type basicRecord
    10 next01 HEX(20);
    10 next02 HEX(20);
  end

  Record myStruct02 type basicRecord
    10 myFirst myTypedef;
  end

The second structure is equivalent to this declaration:

  Record myStruct02 type basicRecord
    10 myFirst;
      20 next01 HEX(20);
      20 next02 HEX(20);
  end

The primitive type of any structure item that has subordinate structure items is CHAR by default, and the length of that structure item is the number of bytes represented by the subordinate structure items, regardless of the primitive types of those structure items. For other details, see Structure.

The following restrictions are in effect in relation to SQL records:
- If an SQL record part uses another SQL record part as a typedef, each item provided by the typedef includes a four-byte prefix. If a non-SQL record uses an SQL record part as a typedef, however, no prefix is included. For background information, see SQL record internals.
- An SQL record part can use only the following types of parts as typedefs:
  - Another SQL record part
  - A dataItem part
Finally, neither a structure nor a structure item can be a typedef

Form as a typedef

You can use a form part as a typedef only when declaring a program parameter.

Related tasks
Creating an EGL program part

Related reference
EGL statements
SQL record internals