Unfinished/closed/opaque/quarantined objects

Assume you want to initialize two objects a and b that point to each other. Then you cannot completely initialize a before creating b, of course, and vice versa.

Other object-oriented languages, like C++ or Java, solve this problem simply by forgoing a complete initialization discipline:

A C++ or Java constructor need not fully initialize a new object. Rather, initialization of an object may be scattered over large parts and various stages of an application run in these languages. These long-distance dependencies will make it rather confusing and unclear frequently, in which state of initialization an object is at a certain point in a program and thereby increases the danger of inadvertent access to not yet initialized members considerably.

We consider this absence of a stringent and statically checked initialization discipline as a major source of run time errors and as a serious obstacle on the way to more comprehensible and maintainable programs. The latter goals can be reached only if we strictly avoid long-distance effects and dependencies and strive for more "locally comprehensible" programs.

In Lava, the basic idea on how to solve the problem of improper use of still unfinished objects is to provide a specific attribute "closed" that can be added to the declaration of a local variable, formal parameter and self object of methods, and to disallow all references to the members of "closed" objects: "Closed" objects are in this sense "opaque" or "quarantined". (Use the tool button on the "Exec switches toolbar" to declare a local variable "closed".)

Furthermore, LavaPE restricts and controls the propagation of such unfinished objects at programming time in order to make completely clear which objects might be infected (possibly deeply nested in their internal structure) at any place in a program with "the bacillus of incomplete initialization" and will be treated as closed/opaque/quarantined in their entirety therefore:

• The actual origin of unfinished objects are the self objects in initializers. At any point in the exec(=body) of an initializer LavaPE knows whether values have already been assigned to all mandatory members of self at this point. At places in the initializer's exec where this condition is not yet fulfilled, self is treated as "closed" in the above sense. Even at places where the object has already been completely initialized we may be forced to treat the object as closed, namely if potentially unfinished objects are passed to this initializer through closed input parameters, since they may have "infected" the self object.
• Any object that is already known as a potentially unfinished object can be propagated in the following ways (but, of course, only if the target has also been declared "closed"):
  1. Within an initializer you can assign closed objects to (direct, top-level) members of the self object.
  2. You can assign a closed object to a non-top-level member of self or to a (possibly nested) member of any other object x if self or x, respectively, has been declared "closed" explicitly. (Note, however, that such an assignment is possible only if the receiving parent object is a state object.)
  3. You can assign closed objects to closed local variables and output parameters of the current exec.
  4. You can use a closed object as an (actual) input parameter to a method invocation if the corresponding formal input parameter has been declared "closed".
  5. You can use a closed object x to call a method m:
     call x.m(...),
     provided the self object of m has been declared "closed".

These rules guarantee that unfinished objects are recognized as such and propagated only to "closed" variables, and their members can never be referenced.

Note 1: A newly created object is always guaranteed to be completely finished unless you pass a closed object as an actual input parameter to the object's initializer and insert it anywhere in the new object.

Or loosely speaking: Incompleteness can be propagated in upward direction in the programs call stack only if it has been passed downward before.

Note 2: For the sake of simplicity the "closed" attribute cannot be assigned to individual member variables of Lava classes but only to local variables, function parameters and the self variable of functions.

Note 3: All combinations of the mandatory/optional and closed/non-closed attributes are possible for local variables and function parameters.

Note 4: If a Lava class A is derived from certain base classes then every initializer of A calls a base class initializer for every base class before initializing its "own" member variables. So, when the base class initializers are called, the self variable of A is still unfinished, and therefore the respective base class initializers may be invoked only if their attribute "self is closed" is set to true. (This is the default for the automatically generated default initializer of a Lava class.)

See also

Complete initialization checks

Multi-phase and recursive initialization