EDT:Language Overview02

EGL types and values

The next sections move from general comments to a review of EGL native types, custom types, classifiers, annotations, and stereotypes.

General comments on types and values

In general usage, a type such as integer or string defines a set of values and a set of operations that can be applied to those values. For example, integers are whole numbers that can be added, subtracted, and so forth; and the number 5 is a value of that type.

The meaning is much the same in EGL, where every value is “of a type.” The type defines the structure of the value and the set of operations that can be applied to the value.

Types can be categorized in different ways, and we initially distinguish between reference and value types:  

• A reference type defines an object, which is a value in a memory area that was separately allocated to hold the value. The object is referenced from some logic and is an instance of the type. In this case, the words "value," "object," and "instance" are interchangeable.
• A value type defines a value that is embedded in an object.

A field declaration is a coded statement that declares a value in a memory area. If the value is based on a reference type, the memory area typically holds an address that points to the value. If the value is based on a value type, the memory area contains the value itself.

The difference between reference and value types has practical effect when you are assigning a value from one memory area to another. [ details to follow ]

Variables and constants

A named field declaration includes an identifier that names the memory area for subsequent use. If the embedding code is allowed to update the area, the identifier is a variable. If the update is disallowed, the identifier is a constant. 

Consider the following field declarations:

   // variable declaration
   NumberOfCars INT;    
   
   // constant declaration
   const MINIMUMNUMBER INT = 2; 

The type is each case is INT, which is a value type for four-byte integers. The first statement declares a value variable, the second declares a value constant.

For a second example, you might declare a list of integers by coding a statement like one of these:

   // variable declaration
   NumberOfVehicles INT[];

   // constant declaration
   const MINIMUMNUMBERS INT[] = [1,2,3,4,5];

The type in this case is INT List or INT[], which is a reference type. The first statement declares a reference variable, which means that you can assign a different list to NumberOfVehicles later. Incidentally, you can also change the values inside the list and can change the number of elements.

The second statement declares a reference constant, which means that you cannot assign a different value to MINIMUMNUMBERS. However, even in this case, you can alter the values inside the list and can change the number of elements.

The behavior is consistent because each declaration is referring to a list, not to an element in a list. The constant is only constant in the sense that the area identified as MINIMUMNUMBERS must always contain the same address, which refers to the same list. The following, subsequent assignment is not valid even though the values are the same:

   // An invalid assignment
   MINIMUMNUMBERS = [1,2,3,4,5]; 

Nullability

In some cases, a reference type is nullable, which means that a variable of that type might refer to an object or might not. 

A variable that is declared to be of a nullable type is called a nullable variable. If such a variable does not refer to an object, the variable is said to be null, with no value at all.

To indicate that a type is nullable, add a question mark to the end of the type name. For example, here is another List declaration:

   myList Int[]?;

After that declaration runs, myList is null.  You might assign a value to myList and then reset the variable to null, as shown next: 

   myList = [1,2,3,4,5]; 
   myList = null;

In EGL, you can make any variable nullable, even a value variable. For example, Int is a value type, but after the following code runs, myInt is null: 

myInt Int?;  

The variable continues to behave as a value variable when used in a statement that assigns a value. 

Instantiability

A type is instantiable if you can create a instance of that type by using the new operator. For example, an EGL dictionary is a reference variable that is composed of a set of entries, each of which is a key and a related value. Here is how you might instantiate a dictionary:

myDictionary Dictionary = new Dictionary
                              { lastName  = "Twain",
                                firstName = "Mark"  };

EGL offers the following convenience:  you can declare an instance of an instantiable type without using the new operator. Here is an example, which is neither more nor less efficient than the previous one: 

myDictionary Dictionary 
             { lastName  = "Twain",
               firstName = "Mark"  };

Alternatively, the instance can be created without content, as here:

myDictionary Dictionary;

When an instantiable type is nullable, you must instantiate the type explicitly. For example, the following code declares a nullable variable and sets it to null, without creating an instance:

myDictionary Dictionary?;

For a second but invalid example, consider code that tries to assign field values to a null variable: 

// error at compile time
myDictionary Dictionary? 
             { lastName = "Twain",
               firstName = "Mark" }; 

One way to correct that error is to instantiate the dictionary in the same statement:

myDictionary Dictionary? = new Dictionary
                               { lastName = "Twain",
                                 firstName = "Mark" };

You can instantiate any EGL value type, although doing so merely places the default value for the type into the memory area.  For example, the following code assigns 0 to myInt:

 myInt Int = new Int{};

The value variable continues to be a value variable.

Last, several EGL reference types are not instantiable: 

• In some cases, a variable of a non-instantiable type receives an object from the EGL runtime code, but only when the variable is used in a particular way. Such cases apply in SQL processing and in service access; and in those cases, the variable must be nullable.  
• A singular case is the Any type. At run time, the related variable can take on the characteristics of one type or, later, another type. That variable must be nullable unless the declaration statement includes an initial value.
  
  Here is an example where the variable is not nullable:

myAny Any = new Dictionary;

EGL native types

EGL Core defines a set of native types, which are implemented only by extensions such as Eclipse IDE for EGL Developers. The most elemental are the simple types. They have no sub-fields and can be categorized as follows:

• Boolean, which is the basis of a field that contains the logical true or false.
• Character types 
• Timestamp types
• Large object types
• Numeric types

The following native types are also defined in EGL Core and implemented by Eclipse IDE for the EGL Developer: 

• ANY, which is the basis of an instance that can reference a value of any type.
• Dictionary type, which is the basis of a dictionary. A dictionary is composed of key-value
  pairs that can be increased or decreased in number and otherwise updated at run time.
• List types, each of which is the basis of a list. A list is a dynamic array: an ordered sequence of elements that can be increased or decreased in number and otherwise updated at run time.

Custom types and EGL classifiers

EGL provides a variety of classifiers, each of which is a kind of type. The capabilities of a classifier are made available to your code in various situations; most often, when you define a custom type that is based on a classifier.

Characteristics of custom types

Depending on the classifier, a custom type can have some or all of the following characteristics:

• A header, which is always required. The header includes the classifier name; the name of the custom type; and, in some cases, a stereotype.
• The end keyword, which is the last detail in the type definition.
• A set of members:
  • Fields, each of which is based on a native or custom type.
  • Functions, each of which is a logical unit that is equivalent to a function or method in another language. EGL functions do not embed other functions.
  • Constructors, each of which is a logical unit that creates an instance of a reference type.

The members in a custom type are typically accessible in the same type. However, if you declare a member to be private, the member is protected from external access; it can be accessed only within the same type. If you do not declare a member to be private, it is said to be public.

Kinds of classifiers

The next table lists the classifier provided in EGL Core. 

Kinds of classifiers

Name	Purpose
DataItem	To alias a native or custom type.
Delegate	To define a type that identifies a kind of function. The related variable is like a function pointer in C language.
Enumeration	To define a type that holds a collection of named values. The value of the related variable is one of those values.
ExternalType	To define a type that identifies non-EGL code. The related variable provides access to the code.
Handler	To define a type that includes all the possible kinds of members. The related variable either defines a general purpose object or allows for interaction with a user interface technology.
Interface	To define a type that represents a contract between a unit of logic such as a service and the logic requester. Uses are twofold: To enable access of the unit of logic, EGL code declares a variable that is based on the Interface type.  To ensure that design decisions are fulfilled, you can code the unit of logic to reference an Interface type.
Library	To define a static type that contains fields and functions that are local to other EGL logic. The fields retain values across requesters.
Program	To define a static type that has a single entry point.
Record	To define a type that includes fields.
Service	To define a static type that has multiple entry points and that might be accessed locally or remotely.  The type also can be the basis of a variable that provides access to the logic from other EGL code.

To extend a capability, an extender makes an additional stereotype available for use with an existing classifier. The list of classifiers is a fixed aspect of the language.

Annotations

When you write EGL source code, you set annotations. They are values used by some aspect of EGL technology; in most cases, by the EGL compiler. 

Annotations help ensure that your EGL-created output reflects your intent. You can set them when you define custom types; when you declare variables and constants; when you code a subset of EGL statements; and, in some cases, when you declare functions.

For example, when you declare a field in a user-interface form, you might set a YES value in the InputRequired annotation. That setting causes the EGL generator to store a detail in the generated output, and the detail ensures that the user can submit the form only if the specified field has content.

Annotation types

An annotation is a value that is based on an EGL Record type. To understand this, consider the following declaration:

myCarCount Int{ @InputRequired{yes} }; 

That code has effects at two different stages:

• It declares the myCarCount variable. The appropriate declaration statement is generated into the output code, and the related instance is available at run time.
  

• The example also identifies an instance that is available at transformation time. The type of that instance is InputRequired.
  
  Here is the EGL Record type:

Record InputRequired type Annotation
   value Boolean;
End

Annotation syntax

@InputRequired { value = yes }

The at sign (@) indicates that you are declaring an annotation, and the characters "InputRequired" indicate that the annotation is based on the InputRequired Record type. The next characters then assign content to the fields in the annotation.

The following example shows an annotation being declared with multiple fields:

@AnotherAnnotation { field01 = "test", field02 = 5 }

An annotation can be based on a Record type that only has fields with default values. Here is an example:

Record ThirdAnnotation type annotation
   value Boolean = true;
end

In that case, the mere presence of the annotation is meaningful to the EGL system code, and only the at sign (@) is required. Here is an example declaration:

@ThirdAnnotation 

If an annotation contains only one field, the name of the field does not have to be specified when declaraing the annotation.  Here is an example:

@InputRequired { yes }

In many cases, you can declare multiple annotations, one separated from the next by a comma. For example, the following code declares the InputRequired and IsDecimalDigit annotations: 

myCarCount NumberOfCars {
   @InputRequired{yes}, 
   @IsDecimalDigit };

Most annotations have a relatively small effect. For example, the InputRequired annotation specifies whether a field in a user-interface form is generated in one way or another. But a stereotype is an annotation that affects a series of decisions; the effect is greater.

Stereotypes

A stereotype is an annotation that you set to communicate a major decision to the EGL compiler. In response to the stereotype, the compiler processes your code in a way that differs depending on which stereotype is specified.

For example, you can declare a Handler type that does not include a stereotype. In this case, the Handler type is the basis of a basic handler, which is a variable that contains fields, functions, or both.

In contrast, if you declare a Handler type that includes the RUIHandler stereotype, the handler provides a way to interact with a web browser for the purpose of maintaining a web page at run time.

Consider the following Handler type: 

Handler MyHandler type RUIhandler{
   initialUI =[myButton],
   onConstructionFunction = start}
   
   myButton DojoButton{ 
      onClick ::= myButton_onClick }; 
   
   function start()
      myButton.text = "Toggle on";
   end

   function myButton_onClick(event Event in)
      if (myButton.text == "Toggle on")
         myButton.text = "Toggle off";
      else
         myButton.text = "Toggle on"; 
      end
   end
end 

The type clause refers to the RUIHandler stereotype, which causes the Handler type to be deployable, unlike a Handler type that has no stereotype. The example code displays a web page that responds as follows to a button click: changes the button text from "Toggle on" to "Toggle off" or from "Toggle off" to "Toggle on". 

The presence or absence of a stereotype also changes the capabilities provided by a Library type. For example, when you declare a Library type without a stereotype, the type contains fields and functions that might be available to multiple handlers. However, when you declare a Library type with the RUIPropertiesLibrary stereotype, you define a library containing fields that that holds values provided from a properties file at run time.

To see that a stereotype is a kind of annotation, compare the following, equivalent outlines for the MyHandler handler:

Handler MyHandler type RUIHandler
                  { 
                      initialUI =[myButton],
                      onConstructionFunction = start
                  }

   // handler members are here 

end

Handler MyHandler { @RUIHandler 
                    { 
                       initialUI = [myButton],
                       onConstructionFunction = start
                    } 
                  } 

   // handler members are here

end

Although the second, longer form is rarely used, the at sign (@) again declares a value used by an EGL compiler. In this case, the declaration is based on the Record type named RUIHandler, which includes several fields:

Record RUIHandler type Stereotype
   {
      targets = [ElementKind.handlerPart],
      defaultSuperType=View,
      validationProxy = 

         // split onto two lines for better display
         "org.eclipse.edt.compiler.binding.
         annotationType.RUIHandlerAnnotationTypeBinding"
   }
   onConstructionFunction FunctionMemberRef;
   includeFile String;
   cssFile String;
   title String;
   theme String; 
end

The RUIHandler Record initializes 3 fields in the Stereotype type:

• targets indicates the custom types for which the stereotype applies. The term "part" is sometimes used in place of the term "custom type," and the ElementKind.handlerPart value indicates that a Handler type can be annotated with a value of type RUIHandler. The absence of any other ElementKind value indicates that no other kind of custom type can be annotated in the same way.
• defaultSuperType indicates that the Handler type being stereotyped will be compatible with the View type, and all fields and functions in the View supertype are available to it. In particular, the custom Handler type has access to the initialUI field, which lists the widgets for initial display on the web page.
• validationProxy identifies a Java class that validates the stereotype value with which the custom Handler type is annotated.

The RUIHandler Record type also declares a set of fields, which are available to any custom type that declares a RUIHandler stereotype. The earlier code identified only one of those fields: onConstructionFunction, which references a constructor that runs initially, before the user accesses the web page. These fields are properly called annotation fields or, more specifically, stereotype fields.   

If you annotate a custom type with a stereotype, and if the custom type can include fields of its own, the stereotype can declare an annotation of type MemberAnnotations. The purpose is to list the annotations that can be appled to each field of the custom type. Here is an example of such an annotation:

Record ExampleStereotype type Stereotype
{
   targets = [ElementKind.recordPart],
   memberAnnotations = [Annotation01, Annotation02]
}

// stereotype fields are here

end

The developer of the custom type can annotate each field with Annotation01 and Annotation02, which are also Record types of type Annotation.

Each classifier supports zero to many stereotypes. For example, a Handler type can include a declaration of RUIHandler or RUIWidget. A developer who codes a custom type selects from the stereotype list that is specific to a classifier.

♦ Next:  Packages and type-name resolution

♦ Previous:  Introduction