The name of a function parameter may contain only letters, digits, and "_". The first character must not be a digit.
Indicates whether the type of this formal parameter shall be substitutable, i.e., whether the type of a corresponding actual parameter may also be p-derived (rather than c-derived) from this formal parameter type. (Cf. the ModelManyViews and CarMeeting samples.)
If checked, then this means that the actual parameter may be in a not yet fully initialized state. Although an object may be passed as an input or output parameter only if non-null values have been assigned to all its non-optional member variables, these values might in turn contain non-fully initialized nested members. LavaPE enforces already at programming time(!) that such unfinished objects are in a sense "closed" or "opaque": Read access to their members is forbidden, and you cannot use their members as "self" objects of method invocations. A "closed" object may only be passed, assigned and referenced "as a whole". Read and method call access to its member objects is prohibited (and prevented by LavaPE at programming time).
The type of the current function parameter may be selected from the combo-boxes "Basic types" and "Other types". "Basic types" lists all classes whose declaration is contained in the basic include file std.lava. If you don't explicitly select a type for a new function parameter then its type will be String.
The object category of a function parameter may be value object (default) or state object or same as "self". The latter means that the parameter's category equals that of the function's "self" object (which can, of course, be determined only on the callers level).
The mode of a function parameter may be mandatory (default) or optional. If optional, the parameter may assume the special null value Ø ("undefined"). Note that all combinations of mandatory/optional and closed/non-closed are possible
In Lava, function parameters are either input or output parameters. For reference parameters it wouldn't be clear whether or not the function assigns a value to them, whereas a Lava function must assign a value to every non-optional output parameter, and this is checked already at programming time (= statically).
This is an essential prerequisite for all kinds of Lava initialization checks since only then you can also cover those cases where a variable is initialized by being an actual output parameter of a function call.
Note: Though function parameters aren't passed "by reference" in Lava, they are yet passed "by address" and never "by value" (= copied).
Assignment of optional to non-optional variables can be checked only at run time and may cause a null-pointer-exception to occur.
Like the member initialization checks (see above), the initialization checks for output parameters are performed at all return points of the function body.
An exception-throwing throw statement is the only way to exit from a function if you cannot assign a value to every non-optional output parameter. (Checked at programming time.)
In this way Lava makes sure that undefined outputs cannot be used inadvertently by the caller of a failing function but only if the resulting exception is caught and the respective output parameters are used nevertheless thereafter.
(The worst thing that may happen then is that such an output is Ø: then a null-pointer-exception will be thrown in turn, or you use the output although its value may be meaningless in this case: that's your own risk and should be avoided without reliable knowledge about the function's implementation.)