Document made on: 05/20/2000 by `manus'. Purpose: ======== To explain recent modification on execution table, dispatch table and indexing using `body_index' instead of `body_id'. Origine of change: ================== An incrementality bug found when developing the EiffelVision 2 library. The scenario was the following: you have many classes that merge a deferred feature with an attribute. When you were changing a class that is inherited from the class that defines either the attribute or the deferred feature and then changing only one class that does the merging, you add the bad surprise of seeing the merged features of all other classes that have not been changed to loose their encapsulation function in workbench mode. The reason was that when doing the small change after the big one, only one body id was changed, not all of them. And also because their execution unit was still referencing the old body_id that is no longer valid anymore, we were removing when shaking the `dispatch_table' and the `execution_table'. To be clearer, here is an example: class A end class B inherit A feature item: INTEGER is deferred end end class C feature item: INTEGER end class D inherit B C end class E inherit B C end Simply compile this system. Everything works fine. Now modify A by simply adding a feature: class A feature f is do end end Recompile, it will recompile all descendants of A. Everything is still fine. Change D and add a new feature: class D inherit B C feature g is do end end Refreeze, your system is not valid anymore, because the EXECUTION_UNIT of `item' in the context of D and E had a new body_id with the first compilation. With the second compilation, only the body_id of `item' in D has been changed in the associated EXECUTION_UNIT, not the one from E. Therefore when we shake the table, it discard the EXECUTION_UNIT of E because associated to a dead body_id. What has been changed: ====================== We notice that we did not need to make a correspondance table between `real_body_index' and `real_body_id', it was largely enough at run-time to have only the `real_body_index' to perform a call. This had the consequence of using EXECUTION_TABLE instead of DISPATCH_TABLE which becomes now obsolete. The set of EXECUTION_UNIT is now fixed and we reassign to a new melted feature the same EXECUTION_UNIT of its frozen couterpart. As a result we are loosing the nice idea of `frozen' feature whose `real_body_id' was below `zeroc'. Now, it is simply the same execution unit and instead of using `zeroc' it is simply better to talk about the number of frozen features instead. We did the change in a step-by-step fashion. First we decide to use the `body_index' to compute the body_id as it was done before, but this was not satisfactory because a body_id change too many times. This implies us to use the body_index to generate the name of features and had the consequence of make us change `feature_name' from ENCODER so that it takes a BODY_INDEX instead of a BODY_ID and we had to change all its caller. The key benefit is that ìn generation we do not need most of the conversion function between body_index and body_id. Interesting things: =================== An incremental issue has been found: when an ATTRIBUTE_I had to be generated in current class (eg redefinition of a function into an attribute) and when we were removing the things that should have make it not to be generated in current class, it was still generated in, because the `generated_in' flag was not reset when taking the old ATTRIBUTE_I information to update current feature table. Going further: ============== To make things more consistency we started to replace all use of body_ids by the use of body_indexes. We have done it for dead code removal, inliner and the BYTE_SERVERs. Problems: ========= We now have an incrementality problem when changing the signature of an existing feature. Because the generated C code will still use the same pattern id to call the new melted code where it should have generate a new one. A workaround is to freeze. Fix for pattern: ================ We should now store the body_index with each pattern_id instead of storing this info in the EXECUTION_UNIT.