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

Decoding

Decoding of a TYPE_A always occur within a context. This is needed to resolve the case of LIKE_CURRENT_TYPE and FORMAL_TYPE. 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 our 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 it computed the ID for `like item'.

In pseudo-C code it looks like:

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

In melted code, we do include them in the encoding, because the interpreted 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 C code before passing it to our type resolver.