Sidebar
This is an old revision of the document!
Table of Contents
2.3.4.8.4 Operation Data
Overview
Any particular operation within an Object is generally Imperative in nature. This means that the Operations are composed of a set of statements. As the program steps through the Operation and executes each statement (i.e., instruction) the state of the Object is changed. Some statements change the values of the Field Data while others change the flow of execution through Control Flow operations (i.e., IF / ELSE IF / ELSE / ENDIF, or FOR LOOPS | WHILE LOOPS /, etc.).
As the statements are executed, the Program Counter for the Operation is also modified. Note: Rarely all the statements contained within a single operation, but relies on calling and executing other Operations. Therefore, most Operations are also considered a Procedural Language. Figure 1 provides a graphic of the difference between Imperative and Procedural Programs.
To confuse the situation even more, there is a differentiation between the Imperative or Procedural: function, procedure, and method.
| function | a named set of instructions that perform a task and return a single value to the caller of the function. Generally, all the parameters passed to the function are considered IN (i.e., Read-Only). |
| procedure | a named set of instructions that perform a task and do not return any values to the caller. The results of the procedure call are changes made to the parameters which can be declared, IN, OUT (i.e., Write-Only), or INOUT (i.e., Read-Write). Procedures often behave like functions in that they return a single value to the caller. The value can be a success flag or a return code. The caller can examine the results to help control the flow through the program. Most modern languages would rather use Exceptions instead. |
| method | a function or a procedure that is associated with an Object in OOP. |
- Note: Regardless of the classification of the set of instructions, there should be no unintended side effects from calling the function. For example, calling a function should not affect anything else in the system. For example, calling a square Root function should not start a printer.
- Note: The use of Exceptions requires that the caller has an Exception Handler. Therefore, most modern Object-Oriented (OO) languages require the declaration of known Exceptions in the specification of a function, procedure or method.
Exceptions
An important aspect of executing any set of instructions is What happens if there is an error?. The error condition could arise from the data passed is not syntactically or semantically correct, it could be that the parameters cause a runtime error, or it could be system related. Some of the most common runtime errors are as follows:
- Dividing an integer by zero.
- Accessing an element that is out of range of the array
- Trying to store a value into an array that is not compatible type
- Passing an argument that is not in a valid range or valid value for a method
- Striving to use a negative size for an array
- Attempting to convert an invalid string into a number
DIDO Specifics
An interesting phenomenon about many of the DIDO Platforms, is the way they treat Operation Data. Many of the Platforms not only distribute Field Data using Distributed Ledger or Journal, they also distribute the Operation Data in the same way (in essence, treating the software just as any other data). When changes are made to the Operation Data, a Transaction is created to be pushed to the Node Network.
General Methods
[char]New Section -- review
