The name of a function may contain only letters, digits, and "_". The first character must not be a digit.
You may change the names of functions, member variables and virtual types when you override them in a derived class or pattern (for instance in order to resolve name collisions in cases of multiple inheritance). They inherit the names of the base versions by default (and their name is changed accordingly if the inherited base name is changed).
Check this check-box if you would like to assign a different name (which will not be changed then if the base name is changed). But note that you have to provide a new implementation for overridden functions. Also note that all Lava entities have a unique internal identifier. Therefore name clashes caused by multiple inheritance actually doesn't matter in Lava since the external, readable identifiers are not used and not needed for the distinction of Lava entities. The only problem is that the programmer possibly cannot distinguish these entities at first sight but has to click the "go to declaration" button to this end.
You can also use one of the usual operator symbols for relational and arithmetic operators for your new function instead of a name. The number of arguments and their types are determined automatically in this case.
Handler functions aren't introduced through this dialog but through the Lava form view. They serve as handlers for GUI events. If a handler function has been introduced in this way then it appears also here in the ordinary Lava declaration tree and can, for instance, be deprived of its handler status and changed into a quite normal non-handler function.
Every class (except for component object interfaces) must have at least one initializer function. Initializers are used to bring newly created objects into a state where all their non-optional member variables have a non-null value. Member functions may be invoked for a new object only after this state has been reached. Base initializers are called automatically for every base class at the beginning of the body of any initializer in order to properly initialize the base parts of the current object.
In Lava you must always specify an initializer (rather than a creatable class) when using a new expression to create a new object.
A default initializer has no arguments. It is suppressed in new expressions and this way enables a more compact syntax of new expressions.
A protected function can be invoked only from functions contained in the implementation of this or a derived class.
A class may have static member functions. These are invoked without call expression and have no "self" variable. Interfaces with static member functions are used primarily if you want to add further functions to an existing class C of objects without extending C.
Example: Mathematical functions that can be applied to Integers/Floats/Doubles but that are not contained in the Integer/Float/Double interfaces: You may declare then, for instance, a class "Math" containing static functions "sin", "cos", "exp", "log", etc. that accept "Float x" as input parameter and you can invoke these in the usual form "sin(x)", rather than "x.sin()", "log(x)", rather than "x.log()".
Note: Lava doesn't make a distinction between virtual and non-virtual non-static member functions of classes, as for instance C++ does, but all non-static member functions are virtual automatically and thus may be overridden in derived classes.
Note: To call a non-static function statically means that you circumvent the usual virtual function call ("late binding") mechanism but you specify precisely which version of the function from which class shall be called. If f is a member function of A then f can be called statically only from derived classes in Lava, i.e., from functions that are declared in a derived class B of A or in the implementation thereof. So if functions are declared in A and overridden in B then clients of B are forced to use the overridden version; they are not allowed to statically call the base version.
An abstract function is not implemented in the implementation of the containing class. Its implementation is deferred to a derived class. Interfaces containing abstract functions cannot be creatable; therefore the "abstract" check-box is disabled if the function belongs to a creatable class.
If checked, then this means that the self object of this method may be in a not yet fully initialized state. Although a method may be called only if a non-null value has been assigned to all non-optional member variables of its self object within the object's initializer, these values might in turn contain non-fully initialized nested members. LavaPE guarantees that such unfinished objects are in a sense "closed" or "opaque": A "closed" object may only be passed, assigned and referenced "as a whole". Referencing its member objects is prohibited (and prevented by LavaPE already at programming time!).
Select "Self is immutable" if the function doesn't change the immediate and nested constituents of "self".
See native interfaces.
Check this if the function shall be eligible as a signal function in the context of the Lava callback concept.
A function is executed in synchronous mode by default, i.e., the caller waits until it returns.
If a function is to be executed in concurrent mode then a concurrently executing thread is allocated and assigned to it.
Autonomous execution means concurrent execution but, moreover, the function neither has output parameters nor can it throw exceptions.
A function may throw exceptions (using the throw statement) of one or several types that you must select here: throw may only throw exeptions that are compatible with some type from this list.
Transforms an overridden function into a non-overridden function, as if it had been newly declared in the containing class.
Check this if the function's implementation is meaningful only in the context of its containing class and must not be invoked with a call object from a more derived class.
As a consequence, LavaPE forces the programmer to override the function whenever another class is derived from its containing class C, and if C is contained in a pattern P and a pattern P' is derived from P then LavaPE automatically includes a derivation C' of C in P', and C' contains an overridden version of the function in question. Static calls from a more derived class / pattern context are forbidden and prevented either.
This may be necessary particularly if a local variable or formal parameter whose type is virtual occurs on the target side of an assignment in the body of this function and the source side of the assignment is of a non-virtual, concrete type.
Example: the right-hand side is a "new C" expression or a constant, the left-hand side is a variable having some virtual type whose concrete value is C in the context of the function body. This is the typical purpose and behavior of a "factory function" which is overridden when the respective class is specialized.