User Defined Types

Purpose

Getting organized can be aided by having containers that are the right size and shape for items you need to have stored. The language supports user defined types for records and objects that permit creating special storage containers for information. This section describes the creation of user defined types.

User Defined Record Types

Specific aggregate data types can be made to respond to application requirements. These are most easily made in the Snap2Motion plate editor by adding a new type definition:

Type definitions can be made for records and objects. Records are discussed first since they are simpler. The syntax of a record type definition structure is:

Type <type name>=record
  <FieldName1>:<FieldType1>;
  <FieldName2>:<Fieldtype2>;
  <FieldName3>:<FieldType3>;
  ...
  end;

The type name is the name you will use in future variable declarations to indicate a variable with this structure. The field names are the "compartment?quot; labels that you will use to indicate that particular part of the variable. The fields have types described by their respective type names. For example imagine that a drilling machine was designed to drill holes in various locations to various depths. A helpful data structure for such a machine might be:

Holes have a location and a depth. This is reflected in the structure of this variable. The name THole is used to conform to the convention that type definitions begin with a capital T to help direct the reader in understanding the purpose of the symbol.

A function that might use such a type could be:

An array of holes can be made through an array declaration such as this:

Note the use of a constant, as previously discussed, to define the size of the array. The drop-down box does not offer the THole data type but it can be typed into the field directly. All of the holes can then be drilled with this procedure assuming that all of the holes have been assigned:

The array is composed of THoles. Any particular item in the array is a THole and accordingly can be passed as a parameter to a function expecting to receive a THole.

User defined types help elevate the abstraction of a program by allowing the program to manipulate items that are more like items in the actual problem, i.e. a drill is concerned with holes. It is very convenient to be able to directly discuss holes rather than being constantly concerned with lower level details of holes such as x and y locations and drill depths.

User Defined Object Types

Objects are similar to records and have similar type declarations. The difference between an object and a record is that as well as fields representing information, objects can have fields which represent behaviors, i.e. functions and procedures that are specifically understood by that object. These procedures and functions can access the information in the object as well as other procedures and functions. Procedures and functions may be written directly in the body of the type declaration. The type definition for an object is:

Type <ObjectName>=object
  <DataItem1>:<DataItem1Type>;
  <DataItem2>:<DataItem2Type>;
  <Procedure1Name>;
    <procedure body>
  <Procedure2Name>;
    <procedure body>
  <Function1Name:<Function1Type>;
    <Function Body>
  ...
  end;

Object programming kindles the imagination because it invites thinking of objects in much more active terms than the physical object might ever portray. For example the previous hole drilling example can be turned around by making active hole objects instead of having inactive hole records. Consider the following object typed definition for a hole:

As well as specifying the previous data items for a hole there is now a drill procedure allowing holes to "drill themselves". This type of reasoning comes up frequently in object oriented programming where objects take on active responsibilities.

The following program would drill an individual hole:

Drilling through an array of holes now becomes: