Please open IsSelfVirtual.lava in LavaPE.
Motivation of rule 9 in our section on Lava support for genericity, design patterns, and frameworks, which reads:
In object-oriented programming languages the special self or this variable wouldn't be declared explicitly. The class C to which the respective member function f belongs is considered to be also the class of self. But how should we proceed if C occurs also as the value of some virtual type VT? Should we consider self as being of type C or of type VT?
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.
Look into the implementation of function A::fa.