Runtime Type System

Description of all the information related to the type system at runtime.

Introduction

As described in the Runtime Type Encoding page, every type created at runtime has an encoding. Then encoding contains information which enables creation of objects, object tests and getting the type of the i-th generic of a class.

Type nomenclature

At runtime we have to distinguish between 2 types for each object:

• dtype corresponds to {CLASS_TYPE}.type_id
• dftype correponds to a runtime computed type

When talking about those types at runtime, we refer to dynamic type for dtype and full dynamic type for dftype.

For non-generic classes (without an attachment mark), dtype and dftype are the same.

For generic classes, the full dynamic type is computed from the type encoding. We have a mapping between dftype and dtype stored in the C structure eif_cid_map.

Type description

For every computed type, we have a structure EIF_GEN_DER which contains a solved type encoding (formals replaced by actual, generic type replaced by their full dynamic type) as well information about the kind of type it is (TUPLE, BIT, expanded, number of generic parameter).

Creating formal generic

One of the feature of the Eiffel language is to be able to create a formal generic parameter. So if you have:

class A [G -> ANY create default_create end]
feature
	f 
		local
			g: G
		do
			create g
		end
end

you need something at runtime to tell you what the type of `g' is so that you can create the proper object. It is usually very easy to do that without having to add any runtime information if you only manipulates instances of A, but if you are manipulating descendants of A for which the formal generic disappear or changed his position it is harder. For example as in:

class B inherit A [INTEGER] end
class C [G, H] inherit A [H] end

To achieve that, the compiler generates data which tell the type of the formal generic parameter of A in all of its descendants and we use that information to compute the proper type.