"Private" / "protected" / "friend" counterparts in Lava

Private / friend

The Lava counterpart of "private" features of C++ or Java classes are the features contained in Lava implementations. All Lava implementations are completely opaque. You cannot reference any Lava entity that is declared within a Lava implementation from outside that implementation.

The analogous effect can be achieved also for packages by declaring them to be opaque. Within an implementation or opaque package IP you can derive classes from "outer" base classes or declare new classes and share these within IP without making them visible to the outside world.

Implementations of these new classes may be even located in separate Lava files but nevertheless have the same scope (visibility domain) as the classes they implement. The accessibility of implementations at run time is not restricted by these "opaque" specifiers. (Note that implementations need never be referenced expressly in Lava.)

We leave it to the reader to compare this opaqueness notion of Lava with the capabilities inherent in the C++ friend specification or the inner classes of Java.

Protected

If a class A has a feature (= member variable or member function) f and interface B is derived from A then in some cases you would like to prevent users of B to directly access f. By analogy to the C++ and Java "protected" specifier you can declare such a feature to be protected in the associated variable or function property sheet of LavaPE to make f invisible to the clients of B while remaining visible to B and its implementation.

Restrictions concerning static function calls

To call a 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 interface 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 interface 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.