TThe name of a function parameter may contain only letters, digits, and "_". The first character must not be a digit.
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 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
The object category of a formal function parameter may be value object (default) or state object. If the function is a member function of a collection class (derived from one of the built-in classes Set/Chain/Array) then you may want to express that the formal parameter category should be the same as that of the elements of the underlying collection class. Check the check box in this case.
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).
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.)
Lava doesn't support parameter passing "by reference": 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.
Though function parameters aren't passed "by reference" in Lava, they are yet passed "by address" and never "by value" (= copied).
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