If class C is the value of a virtual type V then the self variables
of all methods of C are considered to have type V

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

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.

Where to look and what to do

Look into the implementation of function A::fa.