Properties

Properties are name-value pairs that EGL uses to encode specific information about a part, variable, or statement. EGL defines these properties internally in a number of different ways; EGL programmers need to know only a few important distinctions:

A simple property communicates information to EGL at generation time, and cannot be changed dynamically (that is, at run time). A simple property has only a single field, value. You can use shorthand to set this field by simply equating the property name to an appropriate value in a set-values block (see Set-values blocks). In the following example, displayName is a simple property:
```
DataItem socSecNum INT {
   displayName = "Social Security Number"} 
end
```
A complex property also communicates information to EGL at generation time, and cannot be changed at run time. A complex property differs from a simple property only in that it has multiple fields instead of just one. Each of these name-value pairs is called a property field. You will often see the unary @ operator preceding a complex property, indicating that the operand is a property rather than a field (see @ operator). Also see "Complex properties" in this topic.
An implicit field is a name-value pair that resembles a property, but is not visible to the compiler at build time. Generally these implicit fields are changeable at run time. EGL adds them automatically to parts of a particular stereotype, such as exception records (see The Exception stereotype).
There are also "pseudo-properties" in Console UI . Like simple properties, pseudo-properties are name-value pairs that you can specify when declaring certain types of variables, such as a ConsoleField. Unlike simple properties, they have no effect on generation. These pseudo-properties are often changeable at run time, though some are declared to be read only. For more information, see topics for the particular UI technology.

This documentation uses the term "properties" in a loose sense to refer to all the above variations.

You can set any of these properties in a set-values block, which is described more fully in Set-values blocks. For more information about the properties and values available for a specific part or statement, see the specific property topics for those parts and statements.

The set of valid properties varies by context:

Each type of part defines a set of properties; you can change those properties to modify characteristics of the part. Each Program part, for example, has a property named alias that identifies the name of the compilable unit.
If a part is stereotyped, additional properties are available (see Stereotypes), not only for the part but possibly for fields within the part. For more information, see the specific data access or UI technologies for which the stereotype specializes that part.
In some variable declarations, you can override a property that was specified in the related part definition, but only if the property is meaningful in that context:
- Overriding a property is possible when you declare a variable that is based on a DataItem part (see DataItem part). Consider the following definition:
```
  DataItem IDNumber CHAR(9) 
  {
    minimumInput = 9,         // requires 9 input characters
    isDecimalDigit = yes, // requires digits
    column = "SSN"    // is related to a column
  }
  end
```
  The following statement declares a UI field of type IDNumber, but the statement does not require that the user type digits:
```
  myID IDNumber { isDecimalDigit = no }; 
```
  In this example, the override does not affect the minimumInput and column properties.
- You can override properties of composite parts such as Record parts. The following example defines a record with a single field:
```
Record TestRecord
  y int {color = red};
end
```
  When you declare a variable based on this definition, you can override the value of the color property:
```
myRec TestRecord {y{color = black}};
```
When you declare a primitive type variable, you can set any of the field-level properties that are useful in the context of the variable declaration.
When you declare a record variable, you can assign the redefines property, which cannot be set when you define a part. For details on this property, see "Declaring a record variable that redefines another."

You cannot access simple or complex properties at run time. (You may be able to access implicit fields.) For example, when you create variables that are stereotyped for relational database records, the logic that you write cannot retrieve or change the names assigned to the tableNames property, which identifies the database tables that are accessed by the record. Even if you override a property value in a variable declaration, your program logic cannot change the value that you specify at development time.

The lack of runtime access to such property values means that when you assign the content of a variable or use the variable as a parameter, the property value is not transferred along with the content. Similarly, when you pass a record to an EGL function, the parameter receives the field contents, but retains the properties that were assigned at development time. In other words, the function cannot see any overrides the program has made to record properties.

Variable names and properties

When you assign the name of an EGL variable to a property, use the variable name directly (do not put quotation marks around the name; quotation marks indicate a literal string). Observe this rule with the following properties:

Basic program: inputRecord
JSF handler stereotype: onConstructionFunction, initialUI array elements.
Rich UI handler stereotype: onConstructionFunction, validationByPassFunctions, validatorFunction, viewRootVar .
SQLRecord Stereotype: keyItems
Other properties: msgField, numElementsItem, selectedIndexItem, selectedRowItem, selectedValueItem , selectFromListItem, validatorDataTable, validatorFunction, redefines

Complex properties

In some cases you can specify generation characteristics by assigning a complex property (composed of a set of property fields). The following example declares an EGL service and defines the xml complex property, which contains the details needed to provide access to the service:

myService ExampleService {
   @xml {
      name="HelloWorld",
      namespace="http://my.website/services"} }
...
end

You cannot access either the complex property or its property fields at run time.

Assignment and properties

Properties do not transfer when you assign one value variable to another value variable. Consider the following scenario:

  myVar1 INT {color = red} = 5;
  myVar2 INT {color = blue} = 2;

  myVar1 = myVar2;

After the assignment, myVar1 has a value of 2 and a color of red.

The same thing happens when you pass a variable as an argument to a function. The function receives the value of the variable, but none of its properties.

Reference variables behave differently. When you assign properties to a reference variable, you assign them to the object the variable is pointing to. After an assignment, a second reference variable points to the same object. The following example shows a reference variable assignment:

myDictionary1 Dictionary { caseSensitive=NO };
myDictionary2 Dictionary { caseSensitive=YES };

myDictionary1 = myDictionary2;

After the assignment, myDictionary1 points to the same Dictionary part as myDictionary2, so myDictionary1 is now case sensitive.