Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "EDT:Language Overview02"

Line 88: Line 88:
  
 
*In some cases, the variable related to the type receives an object only when the variable is used in a particular kind of statement. Such cases apply in SQL processing and in service access; and in those cases, the variable must be nullable.    
 
*In some cases, the variable related to the type receives an object only when the variable is used in a particular kind of statement. 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. The related variable is of one type or another at run time, but not of the Any type. In this case, the variable must be nullable unless you instantiate the value of another type in the declaration statement.
+
*A singular case is the&nbsp;Any type. The related variable&nbsp;is of one type or another at run time, but not of the Any type. In this case, the variable must be nullable unless the declaration statement includes an instantiation, as shown here:<br><br>
 +
<pre>myAny Any = new Dictionary;</pre>
 +
&nbsp;
  
 
== EGL native types  ==
 
== EGL native types  ==

Revision as of 16:24, 31 October 2011

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.

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.

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 list 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 in the second example identifies a memory area that contains an address of a second memory area. 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 following statements apply:

  • The variable is said to be null, with no value at all.
  • The memory area named by the variable is holding a value that is characteristic of a null; typically, binary zeros.

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. For example, Int is a value type, but after the following code runs, myInt is null: 

myInt Int?;  

If you append a question mark to the name of a value type, you are identifying a reference type. The Int and Int? types are different; and after the following code runs, myInt refers to an object that contains an integer:

myInt = 4;


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" };


Last, several EGL reference types are not instantiable: 

  • In some cases, the variable related to the type receives an object only when the variable is used in a particular kind of statement. 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. The related variable is of one type or another at run time, but not of the Any type. In this case, the variable must be nullable unless the declaration statement includes an instantiation, as shown here:

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                        
Class
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 represents an area of memory and is based on an EGL type. To understand these points, consider the following declaration:

myCarCount NumberOfCars { 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 type of the variable is NumberOfCars, which is an alias of type INT. Here is the alias, or data item:
DataItem
   NumberOfCars INT
End
  • 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

All annotations are based on one or another EGL Record type.

Annotation syntax

The InputRequired declaration in the earlier source code did not set the value field explicitly. The InputRequired = Yes assignment is a shorthand form of the following code:

@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.

A shorthand form such as InputRequired = Yes is available whenever the Record type for the annotation has a single field, regardless of the name of that field. If an annotation has multiple fields, only the long form of the declaration is valid, as in the following example:

@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 

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 DisplayName annotations: 

myCarCount NumberOfCars {
   InputRequired = yes, 
   DisplayName   = "Number of cars: " };

Annotation overrides

You can declare an annotation when you define a type, and then override the annotation when you declare a variable that is based on the type.

Here is a data item with two annotations:

DataItem
   NumberOfCars { 
      InputRequired = no, 
      DisplayName = "Number of cars: "}
End

The following variable declaration overrides the previous value of the InputRequired annotation:

myCarCount NumberOfCars { InputRequired = yes }; 

If a data item or part includes several annotations and a few are overridden in a variable declaration, the annotations that were not overridden are still in effect. In the previous example, the myCarCount variable is associated with both the InputRequired and DisplayName annotations.

The ability to set multiple annotations is particularly important for data items. For example, a data item might be defined with annotations that are meaningful for user interface and for accessing a relational database. The benefit of being able to specify multiple annotations is that you can retain data items in a library and use those data items for many purposes. When you use a data item to declare a variable for one purpose such as database access, the annotations relevant to other purposes such as user interface have no effect.

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 annotation, the compiler responds in accordance with a pattern that differs from one stereotype to another.

For example, you might want to display a web page that responds as follows to a button click: by changing the button text from "Toggle on" to "Toggle off" or from "Toggle off" to "Toggle on".  The logic is in the following handler, which includes a declaration for the RUIHandler stereotype:

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 

You might want to provide the same capability on a mobile device that runs on the Android operating system. In this case, an extender might provide a pair of constructs...  ??

Handler MyHandler type WindowHandler
   { createLayout = true, contentView = } 

    ????

   myButton DojoButton{ 
      text = "Toggle on", 
      onClick ::= myButton_onClick }; 

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

[ Explain ]

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 Annotation
   {
      targets = [ElementKind.handlerPart],
      @Stereotype {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 type declares three annotations:

  • 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.
  • @Stereotype indicates that the Record type is defining a stereotype. Fields in the View supertype are available to the Handler type being stereotyped. 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 Annotation
{
   targets = [ElementKind.recordPart],
   memberAnnotations = [Annotation01, Annotation02]
   @Stereotype {}
}

// 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

Back to the top