Take your time... don't live too fast.
Troubles will come... and they will pass.
- Ronnie Van Zant and Gary Rossington
The Data Definition statement creates a single data item within the context of where it is defined. If the statement is defined at the module level, the data item stands alone, and is not tied to any class. If defined inside a class, it becomes a member of that class, and if defined inside a method, the data item is local to that method and is only visible within the method.
Inside a method, the data item must only be unique within the statement block where it is defined. A data item can be defined in a nested block with the same name as a data item in an outer block, and it overrides the previous definition within that block only (and nested blocks).
The following table shows four separate permutations of the data definition statement.
♦ The first usage applies to a single data item being defined with an optional initialization expression.
♦ The second usage applies to a single data item being defined with a required initialization expression. The 'data' keyword can be left empty (no data type) if an initialization expression is used. The data type of the expression automatically dictates the data type of the variable.
♦ The third usage applies to an array with the size specified at compile time. The "Size" must be one or more integer constants (based on number of array dimensions), and the array braces must be applied to the DataItem, not the Type. Any number of dimensions may be used.
♦ The fourth usage applies to an array reference with an optional initialization of the array. The array braces must be empty and must be applied to the Type, not the DataItem. Any number of dimensions may be used.
The DataItem identifier name must conform to standard Aztec Identifier syntax rules and it also must be unique within the context of where it is being defined. It is valid, however, to use a DataItem name that already exists in another context that might be covered when the compiler looks for an identifier match. For instance, when an identifier is used inside a method, the compiler first searches for that identifier in the current method. If not found there, it looks within the class where the method is defined (if applicable), and finally it searches the module level data currently defined with the application/script. A data identifier with the same name can actually reside in each of those three contexts. The compiler will use the first one it finds, given the search order just described.
♦ The ‘Type’ is a valid data type and it is required, unless an initialization expression is provided (see below). The type can be a primitive data type, value or reference, a Class reference or a method reference. A data type created with the "type" statement is also valid. The following table shows the reserved keywords which are valid for Type, along with user defined identifiers, such as classes, enumerations and types.
♦ The "ref" keyword is used only with primitive data types, including int, float, string and bool (e.g. data<string ref>).
♦ Array references for any data type are also allowed, as shown in one of the examples above. Refer to the Aztec Array web page for more details.
♦ The "base" keyword can be used to specify generic method reference data types and generic array references. The "base method" combination is a generic method reference and "base[]" is a generic array reference. These are discussed in more detail in the method reference and array web pages.
♦ The following table shows the keywords that are supported within the data definition statement. The 'data' keyword is the only one that is required.
♦ If the data item is defined at the module level (global data)
♦ The DataItem can also contain an Aztec Space (e.g. "aztec.script.DataItem") to define the data item in a space other than the "current space".
♦ The optional initialization expression can be used for individual data items and arrays. During startup, the VM automatically executes the expression(s) and initializes the data item with the result.
♦ The visibility keywords (public, module, space and unit) can be used to control who can access the global data item.
♦ Default visibility is 'module' and default space is 'aztec.script', so no other modules will be able to see the data item unless the visibility is specifically changed.
♦ If the data item is defined at the class level
♦ The DataItem can not contain an Aztec Space - the class which contains the data item defines the space.
♦ If 'shared', only one copy of the data item exists and is shared by all instances of the class.
♦ If an instance data item (not shared), each instance of the class gets its own copy of the data item.
♦ If 'shared', the optional initialization expression can be used. During startup, the VM automatically executes the expression and initializes the data item with the result. The initialization expression can not be used for instance data items.
♦ The visibility keywords (public, private, family, module, space and unit) can be used to control who can access the class level data item.
♦ Default visibility is 'private'.
♦ If the data item is defined at the method level
♦ The DataItem can not contain an Aztec Space.
♦ If 'shared', only one copy of the data item exists and is shared by all instances of execution for the method.
♦ If a "normal" local data item (not 'shared' and not 'const') is defined inside a nested block within the method, the initialization expression will be invoked every time the block is executed. The data item will only be visible within the block (and nested blocks) where it is defined.
♦ The initialization expression can be used for normal local variables and shared local variables. If 'shared', the initialization expression is executed one time at the start of the program, and is not executed again. So any changes made to the shared variable will retain the same changes the next time the method is executed. For normal local variables, the initialization expression is executed every time the method is invoked. Once the initialization expression is executed, the VM automatically initializes the data item with the result. As mentioned above, if the variable is defined inside a nested block, the initialization expression is executed every time the block is executed. Thus, a variable defined inside a loop gets re-initialized every time through the loop. If there is no explicit initialization expression, the variable gets re-initialized with the default value based on the data type.
♦ Visibility keywords are not applicable to a data item defined in a method. It can only be seen within the method.
♦ During script startup, the system automatically executes the initialization expression for all persistent data items, which includes global data items, class 'shared' data items, and method 'shared' data items. The initialization of the persistent data items is currently performed in the following order within a single module, and then the system moves to the next module, if applicable. There is interest in adding an option to the language to offer user control over the order of this initialization, but this is the only order supported right now.
♦ All global (module level) data items are initialized in the order in which they are defined in the source code.
♦ All shared data items in global methods and inside classes are initialized in the order in which they appear in the source code.
♦ Inside a class, once all shared data items are initialized, shared data items inside the class level methods are then initialized.
♦ The 'data' keyword does not have to be the first keyword in the statement, but all keywords (including 'data<>') must come before "DataItem".
Defining Data Items
