Each parameter declared in the Parm rule can be defined to operate as:
- entry parameter (specifying the in operator)
- exit parameter (specifying the out operator)
- entry/exit parameter (specifying the inout operator)
When no operator is specified, it will depend on the following:
- If the object was called with Call, the parameter behaviour will be: inout.
- If the object was called with Udp, and it's the last parameter, it will be an out parameter; if it's other parameter, it will depend on the generation language.
parm([out:&var1, in:&var2, &var3, inout:&var4]);
&var1, &var2, &var3, &var4:
Are -local and temporary- variables defined in the called object.
The following rule is declared in a procedure:
parm(out:&var1, in:&var2, &var3, inout:&var4);
So, we know that:
&var1: Is an out parameter.
&var2: Is an in parameter.
&var3: As no operator is specified, it will depend on the method used to call the object, as was explained previously.
&var4: Is an in-out parameter
Declaring explicitly each parameter behavior, we obtain the following advantages:
1. A better specification of the interfaces semantics. This means that the following will be understood:
- inout: the parameter comes with a value and after executing the called object, the resulting value is returned to the caller object.
- in: the parameter comes with a value and after executing the called object, the resulting value is not returned to the caller object.
- out: the parameter doesn't come with a value and after executing the called object, the resulting value is returned to the caller object.
2. Independence from generation languages. That is, if we specify operators explicitly, whenever applications are generated using different generation languages, the behavior of the parameters will not change based on the default behavior of the corresponding generation language.
3. Optimization according to the architecture in which the applications are generated (this advantage contrasts with the previous advantage). It refers to the following: In most languages, it is more efficient to transfer parameters by reference (inout) than by value (in or out); but in Java, for example, the parameters can only be transferred by value, so, in order to achieve the functionality of transferring them by reference, it is necessary to convert parameters. This can produce significant overhead. Additionally, when executing on a distributed way (Java, DCOM, etc), the out parameters use, has the advantage of making unnecessary to send them as parameters in the call; however, if the parameters are defined as inout, then all parameters must be sent; consequently, more bytes than the necessary are sent, which is rather inconvenient, specially in environments such as the Internet.
The specifier will not allow specifying a program assigning values (in rules/source/events) to parameters defined as in.
When the variable is a complex type (such as a Business Component, Structured Data type, External Object) the parameter is passed by reference; you can modify its state even if it is defined as In: parameter.