EIFFEL VISITOR. With the new functionality of the .NET parser (explicit interface member implementations, support of overloaded names) it was necessary to adapt the existing CW_EIFFEL_VISITOR. See section 2.2.3 for a short description of the Eiffel visitor. An AST node (CW_TYPE, CW_FUNCTION…) has a flag whether it was already visited through a visitor or not. (After the first visit, is_visited is true.) The Eiffel visitor is registered to every feature node type twice. In the non-visited state the features are either extended to creation_procedure_list (CW_CREATION_PROCEDURE_LIST) or feature_list (CW_FEATURE_LIST). Later, the visitor uses these two lists to generate an additional comment for overloaded features. In the actual visit where the visitor generates code for every node type, the visitor distinguishes between public and private features. The code of the feature body – the part between do and end – is only generated when the feature is public, otherwise the body remains empty. A private feature is an explicit interface member implementation of a type (see section 4.2.1). The generated source code of these features is not extended to the list containing procedures or features, but to the list interface_features. Finally, the source code that interface_features contains is written after the {NONE} clause of the current class text. To append the name of a feature to the class text, the visitor now uses overloaded_name instead of eiffel_name. Every feature node has an attribute overloaded_name, which is a unique name of the feature. When the original .NET method is not overloaded, overloaded_name is equal to eiffel_name. For all overloaded features generate_overloaded_comment comments the feature with additional information of the form -- (+2 overloads). This comment means that the class has two other features with the same Eiffel name. Now the creation_procedure_list and feature_list come into play since every feature is registered to one of them. A call of the form feature_list.overloaded_count (a_feature.eiffel_name) returns the number of features that have the same Eiffel name as a_feature. It works similarly with the creation procedures. Due to creation_procedure_list the code generation for the create clause implemented in generate_creation_text is also simplified. When is_by_reference of an argument type is true, the feature generate_feature_type sets type to the actual generic parameter of TYPED_POINTER [G]. The features generate_preconditions and generate_pos...
