Difference between revisions of "Dynamic Binding"
m |
m (→Talking about ids: Routine_id, body_id, real_body_id and type_id) |
||
Line 17: | Line 17: | ||
====Talking about ids: Routine_id, body_id, real_body_id and type_id==== | ====Talking about ids: Routine_id, body_id, real_body_id and type_id==== | ||
− | In a compiled Eiffel system, every feature that is a seed gets its own unique routine_id. Features that are just inherited or are a redeclaration have the same routine_id as their precursor (See [[Routine IDs]]). | + | In a compiled Eiffel system, every feature that is a seed gets its own unique '''routine_id'''. Features that are just inherited or are a redeclaration have the same '''routine_id''' as their precursor (See [[Routine IDs]]). |
− | It is possible for a feature to have more than one routine_id when it has more than one precursor. | + | It is possible for a feature to have more than one '''routine_id''' when it has more than one precursor. |
− | Every routine body, that means every declaration or redeclaration, gets its own unique body_id. | + | Every routine body, that means every declaration or redeclaration, gets its own unique '''body_id'''. |
In the following picture it is shown how these ids could look like: | In the following picture it is shown how these ids could look like: | ||
Line 28: | Line 28: | ||
|[[Image:DynamicBindingABCExample.jpg]] | |[[Image:DynamicBindingABCExample.jpg]] | ||
|} | |} | ||
+ | |||
+ | The '''body_id''' of feature g in A and B are the same since g is not redefined in B. As it will be shown later, the chosen '''routine_id''' have an impact on the dynamic binding semantics. In class C the feature f_b gets the routine_id 1 since it is selected, the not selected feature f of C gets a new '''routine_id'''. | ||
+ | |||
+ | Feature j of class C that redefines both feature g of A and feature h of B gets both their '''routine_id''''s. | ||
====Dynamic binding in finalized code==== | ====Dynamic binding in finalized code==== |
Revision as of 04:26, 10 January 2007
Warning: Warning: Article under development
Dynamic binding is a key feature behind object technology. In the following piece of code:
foo (a: A) do a.f end |
It is not known at compile time, which feature has to be called for call a.f. This depends on the exact type of the object referenced by a, also called its dynamic type.
Talking about ids: Routine_id, body_id, real_body_id and type_id
In a compiled Eiffel system, every feature that is a seed gets its own unique routine_id. Features that are just inherited or are a redeclaration have the same routine_id as their precursor (See Routine IDs). It is possible for a feature to have more than one routine_id when it has more than one precursor.
Every routine body, that means every declaration or redeclaration, gets its own unique body_id.
In the following picture it is shown how these ids could look like:
The body_id of feature g in A and B are the same since g is not redefined in B. As it will be shown later, the chosen routine_id have an impact on the dynamic binding semantics. In class C the feature f_b gets the routine_id 1 since it is selected, the not selected feature f of C gets a new routine_id.
Feature j of class C that redefines both feature g of A and feature h of B gets both their routine_id's.
Dynamic binding in finalized code
In finalized code the dynamic binding is very simple. For every routine_id there exists an array, that maps dynamic type ids to function pointers. The code snipped how the dynamic binding works:
void Fcubdx0 (EIF_REFERENCE Current, EIF_REFERENCE arg1) { ... (FUNCTION_CAST(void, (EIF_REFERENCE)) Txioci5[Dtype(arg1)-50])(arg1); ... }
In this example the type_id for A body_id refers to a certain body of a class. The real_body_id refers a body of one specific generic derivation of a class. The real_body_id is very important in workbench mode. Once the real_body_id is resolved for a call, the rest is just melting ice stuff. In the call to a.f the routine_id of f is known.