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: