Issue 5773: IDL to Ada mapping for valuetypes                                                                                                                                                                       (ada-rtf)
Source: Daimler AG (Mr. Oliver M. Kellogg, oliver.kellogg@eads.com Oliver.Kellogg@t-online.de)
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
Discussion: 

End of Annotations:=====
Sender: oliver.kellogg@sysde.eads.net 
Date: Mon, 02 Dec 2002 16:26:16 +0100 
From: Oliver Kellogg <oliver.kellogg@sysde.eads.net> 
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