Runtime Type Encoding

At runtime, when we need to describe an Eiffel type (TYPE_A instance in the compiler), we use the following encoding:

Legend:

• Words in uppercase refer to constant defined in $EIFFEL_SRC/C/run-time/include/rt_gen_types.h
• Words in red refer to another abstraction described in the above diagram
• Words in green are only appearing for melted code generation
• Eiffel type_id refers to the `type_id' in finalized mode and the `static_type_id' in workbench mode.
• All other words should be self explanatory

Note: We refer to FROZEN_TYPE. This is not yet an abstraction standardized by ECMA and is only present in our runtime for evaluation purpose of this new abstraction.

Decoding

The decoding of a type at run-time always occurs within a context. This is needed to resolve when type involves a formal generic parameter or an anchor to Current. The encoding does not cover the case of anchors to a feature (or an argument for pre-ECMA backward compatibility) because it is not supported by the run-time type resolver.

Instead the Eiffel compiler must generate some code to fill the gap. For the following example:

list: LIST [like item]

the compiler will generate the following encoding:

1. ID for LIST
2. ID for `like item'

meaning that at runtime, we compute the ID for `like item'.

In pseudo-C code it looks like:

typearr = { LIST_ID, 0, TERMINATOR_TYPE};
typearr[1] = Result_of_computation_of_id_of_like_item;

In melted code, we do include them in the encoding, because the interpreter will use the data from the encoding to compute the type of the anchor and then build an encoding similar to the one used for the C code generation before passing it to the run-time type resolver.