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 img 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:

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