A type is either virtual or non-virtual

Sample file

Please open IsSelfVirtual.lava in LavaPE.

Topic

Motivation of rule 9 in our section on Lava support for genericity, design patterns, and frameworks, which reads:

Overview

Roughly spoken, the reason for this rule is that a type cannot be used as a virtual and as a non-virtual type at the same time within the containing pattern, similarly as in C++ a member function of a class cannot be virtual and non-virtual at the same time.

In the C++ case it would not be clear otherwise whether a concrete invocation of that function should be executed as a virtual or as a non-virtual call.

In Lava, without the above rule it would not be clear at check time (but only at run time) whether the type of the special variable self is virtual or non-virtual. As a consequence, a static type check would not be possible in important cases, viz. if self occurs on the right-hand side of assignments or as an input parameter of a function call. In more detail:

Assume that a member function f of a Lava class A is called with a "call variable" c:

call c.f(...)

and that A is the value of some virtual type vt:

<vt> = A

Now if self is assigned to some variable within f then we ought to know whether the type of self is virtual or not, in order to apply the type compatibility rules in our section on "Static type-safety of Lava ".  

The type of self apparently will comply with the type of c. The latter isn't known, however, when the body of f is checked, rather it is known only at run time. If we could choose to declare c as being of the virtual type <vt>:

<vt> c;

or also as being of the concrete type A:

A c;

then we couldn't decide at check time whether the type of self is virtual or not. Rule 9 excludes the second case and this way enables a static type check by removing this ambiguity.

Where to look and what to do

Look into the implementation of function A::fa.