ADA13 — IDL to Ada mapping for valuetypes

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?

No Data Available