Issue 5773: IDL to Ada mapping for valuetypes (ada-rtf) Source: Airbus Group (Mr. Oliver M. Kellogg, oliver.kellogg(at)airbus.com) Nature: Clarification Severity: Summary: The version 1.2 IDL to Ada mapping specification (01-10-42) maps concrete valuetypes into two classes: 1. the class hosted in a package with the mapped name of the IDL valuetype, and 2. a child package of this package named Value_Impl. These two classes are separate and incompatible both in their controlling types (their inheritance graphs are unrelated) and operations (class 1 uses "in Value_Ref" for the controlling parameter while class 2 uses "access Object" for the controlling parameter.) It is felt that this design choice is not sufficiently explained. In particular, it is not obvious why class 2 is not derived from class 1, and it is not explained why the signatures of the mapped operations are incompatible between the two classes. =================== Further Elaboration Other language mappings, such as the IDL to C++ mapping, choose to make the two classes compatible: Class 2 inherits from class 1, and the mapped operations in class 2 override those in class 1 (i.e. they have compatible signatures.) The "Package Pattern for Mapping" (4.4.1) treats valuetypes the same as interfaces. However, the distinct "proxy" and "impl" pattern applied to valuetypes makes necessary extra "Set" operations for associating implementation values with the "proxy" values. The programming of applications is encumbered by the need to cater to two distinct types. During the design of the Ada mapping for valuetypes, has it been considered to have the Value_Impl class inherit from the valuetype- mapped package? (The type Object could perhaps originate in the valuetype-mapped package, the type Value_Ref could be a classwide access to Object, and the methods in that package could have signatures like those in the Value_Impl package.) What were the reasons for not adopting such a mapping? Resolution: Revised Text: Actions taken: December 2, 2002: received issue January 12, 2010: closed issue; Closed; No Change Discussion: The mapping of valuetypes was developed as the result of an RFP process in 1999. The submission for that effort has more information on the rationale for the mapping choices made. In particular, the choice between mapping valuetypes as “pointers” to (dynamically allocated) records (either smart-pointer Ref types or primitive access types) versus the present mapping was examined during this process. The decision adopted was driven mainly by the desire to map both public and private state members of valuetypes, thus two separate “classes”. As to why the valuetype_Impl “class” does not inherit from the valuetype “class”, this would preclude the Impl “class” inheriting from an Impl class mapped from an IDL parent valuetype. It was thought that this was a more important and useful pattern. Since Ada95 doesn’t support multiple inheritance directly, allowing the “implementation inheritance” of Impls precludes any inheritance of Impls from “definition classes”. In these and in other respects the mapping of all “IDL Units” were very similar and so the mapping rules were combined. Disposition: Closed, No Change End of Annotations:===== Sender: oliver.kellogg@sysde.eads.net Date: Mon, 02 Dec 2002 16:26:16 +0100 From: Oliver Kellogg Organization: EADS Deutschland GmbH X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.18-17.7.x i686) X-Accept-Language: en To: issues@omg.org Subject: IDL to Ada mapping for valuetypes - request for clarification The version 1.2 IDL to Ada mapping specification (01-10-42) maps concrete valuetypes into two classes: 1. the class hosted in a package with the mapped name of the IDL valuetype, and 2. a child package of this package named Value_Impl. These two classes are separate and incompatible both in their controlling types (their inheritance graphs are unrelated) and operations (class 1 uses "in Value_Ref" for the controlling parameter while class 2 uses "access Object" for the controlling parameter.) It is felt that this design choice is not sufficiently explained. In particular, it is not obvious why class 2 is not derived from class 1, and it is not explained why the signatures of the mapped operations are incompatible between the two classes. =================== Further Elaboration Other language mappings, such as the IDL to C++ mapping, choose to make the two classes compatible: Class 2 inherits from class 1, and the mapped operations in class 2 override those in class 1 (i.e. they have compatible signatures.) The "Package Pattern for Mapping" (4.4.1) treats valuetypes the same as interfaces. However, the distinct "proxy" and "impl" pattern applied to valuetypes makes necessary extra "Set" operations for associating implementation values with the "proxy" values. The programming of applications is encumbered by the need to cater to two distinct types. During the design of the Ada mapping for valuetypes, has it been considered to have the Value_Impl class inherit from the valuetype- mapped package? (The type Object could perhaps originate in the valuetype-mapped package, the type Value_Ref could be a classwide access to Object, and the methods in that package could have signatures like those in the Value_Impl package.) What were the reasons for not adopting such a mapping? Thanks, Oliver M. Kellogg -- Naval and Ground Operations (NGO2) Systems and Defence Electronics EADS Deutschland GmbH D-89070 Ulm, Germany e-mail: oliver.kellogg@sysde.eads.net tel.: (+49) 731 392-7138 fax: (+49) 731 392-5826 From: Victor Giddings To: ada-rtf@omg.org, Oliver Kellogg Subject: Proposed resolution for issue 5773 Date: Mon, 3 Aug 2009 10:19:23 -0400 X-Mailer: Apple Mail (2.935.3) Disposition: Closed No Change OMG Issue No: 5773 Title: IDL to Ada mapping for valuetypes Source: Daimler AG Mr. Oliver M. Kellogg, oliver.kellogg@eads.com Oliver.Kellogg@t-online.de Summary: The version 1.2 IDL to Ada mapping specification (01-10-42) maps concrete valuetypes into two classes: 1. the class hosted in a package with the mapped name of the IDL valuetype, and 2. a child package of this package named Value_Impl. These two classes are separate and incompatible both in their controlling types (their inheritance graphs are unrelated) and operations (class 1 uses "in Value_Ref" for the controlling parameter while class 2 uses "access Object" for the controlling parameter.) It is felt that this design choice is not sufficiently explained. In particular, it is not obvious why class 2 is not derived from class 1, and it is not explained why the signatures of the mapped operations are incompatible between the two classes. Further Elaboration Other language mappings, such as the IDL to C++ mapping, choose to make the two classes compatible: Class 2 inherits from class 1, and the mapped operations in class 2 override those in class 1 (i.e. they have compatible signatures.) The "Package Pattern for Mapping" (4.4.1) treats valuetypes the same as interfaces. However, the distinct "proxy" and "impl" pattern applied to valuetypes makes necessary extra "Set" operations for associating implementation values with the "proxy" values. The programming of applications is encumbered by the need to cater to two distinct types. During the design of the Ada mapping for valuetypes, has it been considered to have the Value_Impl class inherit from the valuetype-mapped package? (The type Object could perhaps originate in the valuetype-mapped package, the type Value_Ref could be a classwide access to Object, and the methods in that package could have signatures like those in the Value_Impl package.) What were the reasons for not adopting such a mapping? Ada RTF 1.3 Disposition: Closed No Change OMG Issue No: 2095 Document {Report document number} Page 36 Discussion: The mapping of valuetypes was developed as the result of an RFP process in 1999. The submission for that effort has more information on the rationale for the mapping choices made. In particular, the choice between mapping valuetypes as .pointers. to (dynamically allocated) records (either smart-pointer Ref types or primitive access types) versus the present mapping was examined during this process. The decision adopted was driven mainly by the desire to map both public and private state members of valuetypes, thus two separate .classes.. As to why the valuetype_Impl .class. does not inherit from the valuetype .class., this would preclude the Impl .class. inheriting from an Impl class mapped from an IDL parent valuetype. It was thought that this was a more important and useful pattern. Since Ada95 doesn.t support multiple inheritance directly, allowing the .implementation inheritance. of Impls precludes any inheritance of Impls from .definition classes.. In these and in other respects the mapping of all .IDL Units. were very similar and so the mapping rules were combined. Disposition: Closed, No Change Victor Giddings Objective Interface Systems victor.giddings@mail.ois.com