Ada2005 features a new language construct, the "limited with" clause,
which brings direct support for forward declarations to the Ada language.
The mapping of interface and valuetype forward declarations (section 4.9
of the Ada mapping version 1.2) could be much simplified by using this
feature.

In order to preserve backward compatibility, I suggest retaining the current
mapping using the CORBA.Foward packages, but marking that mapping as
obsolescent.

I propose adding a new mapping which takes advantage of the Ada2005
"limited with" clause, accompanied by a recommendation that new code
should use this simplified mapping.

The example given in section 4.9.3 of formal/01-10.42,

interface Chicken;
interface Egg

;
interface Chicken

;

could be mapped as follows:

– code mapped from interface Egg
with CORBA.Object;
limited with Chicken;

package Egg is

type Ref is new CORBA.Object.Ref with null record;

procedure hatch (Self : in Ref; Result : out Chicken.Ref'Class);

function To_Ref (The_Ref : in CORBA.Object.Ref'Class)
return Ref;

end Egg;

– code mapped from interface Chicken
with CORBA.Object;
with Egg;

package Chicken is

type Ref is new CORBA.Object.Ref with null record;

procedure lay (Self : in Ref; Result : out Egg.Ref'Class);

function To_Ref (The_Ref : in CORBA.Object.Ref'Class)
return Ref;

end Chicken;

Introduction of Ada 2005 features into the mapping would be beyond the scope of what
an RTF could do; it would require a full RFP to do this.

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

The IDL to Ada mapping specification version 1.2 (01-10-42)
does not mention how to map reopened IDL modules to Ada.

Since the CORBA specification says that re-opened modules add to the same
module, it was not felt to be necessary to explicitly provide a mapping. However,
a clarifying statement to that effect will be added.

Table 2-1 in section 2.2.4 contains a couple of columns labelled "Applicable to". However the entries in the columes are the number "4". (These are probably meant to be check marks.)

Resolved as suggested: change the numeral “4” to “check mark”.

The current Ada mapping specifies that ada Abstract_Ref types
mapped from IDL abstract interfaces should inherit directly
from CORBA.AbstractBase.Ref, and not from CORBA.Object.Ref.

It seems more natural to us to make Abstract_Ref types inherit
from CORBA.Object.Ref. Otherwise, these Abstract_Ref tagged
types would not inherit thr primitives of CORBA.Object.Ref
(Is_A, Is_Equivalent, Hash)

Resolution:
Close without change. The intended semantics for abstract interfaces are correctly
reflected by inheriting from AbstractBase, rather than Object, as evidenced by the
following section in the CORBA specification:
“3. Abstract interfaces do not implicitly inherit from CORBA::Object. This is because
they can represent either value types or CORBA object references, and value types do not
necessarily support the object reference operations (see Section4.3, “Object Reference
Operations,” on page4-8). If an IDL abstract interface type can be successfully narrowed
to an object reference type (a regular IDL interface), then the CORBA::Object operations
can be invoked on the narrowed object reference.”
Disposition: Closed, no change

Paragraph 5.2.6 of CORBA v2.3.1 specifies that "value type
instances may be widened/narrowed to other value types. Each language
mapping is responsible for specifying how these operations are made
available to the programmer." Ada mapping v1.2 specifies a
To_Abstract_Value function to widen a value type to an abstract value
type (paragraph 1.10.2.2). The same document reads that concrete value
types may be widened to other concrete value types using ada's view
conversion (paragraph 1.10.2.3). However, nothing is specified to
support narrowing of value types (concrete or abstract) to inheriting
concrete value types.

Proposed solution: We propose the definition of a To_Value_Ref function
in the helper package associated with the value type, with the following
signature:
function To_Value_Ref
(From : in CORBA.Value.Base'Class)
return Value_Ref;

The semantic of this function would be to cast the object reference
passed as a paramater to a reference of the current interface, if it
is legal. Otherwise, this function would raise CORBA.Bad_Param.

Proposed solution:
We propose the definition of a To_Value_Ref function in the helper package
associated with the value type, with the following signature:
function To_Value_Ref
(From : in CORBA.Value.Base'Class)
return Value_Ref;
The semantic of this function would be to cast the object reference passed as a
parameter to a reference of the current interface, if it is legal. Otherwise, this
function would raise CORBA.Bad_Param.
Resolution:
Accept as suggested.

4.4.2 "Base types" specifies that PortableServer.Servant_Base
and CORBA.Value.Impl_Base shall inherit from CORBA.Impl.Object.

5.2.3 "CORBA.Value.Base" and 5.2.6 "PortableServer.Servant_Base"
show both types as "abstract tagged null record"s. This contradicts
the aforementioned provision.

The following revision is proposed to resolve this issue:

• In 5.2.3 "CORBA.Value.Base" define type Impl_Base as
  "type Impl_Base is abstract new CORBA.Impl.Object with private;"
• In 5.2.6 "PortableServer.Servant_Base", define type Servant_Base as
  "type Servant_Base is abstract new CORBA.Impl.Object with private;"

Accepted as suggested. However, the definition of CORBA.Local.Object should
also be similarly changed

The IDL to Ada mapping version 1.2 (01-10-42) of valuetypes
causes serious problems when combined with other IDL constructs.

Here is an example:

// file: my_module.idl
module my_module {

valuetype vtype

;

typedef vtype array_of_vtype[10];

/* Further sources of problems:
*
struct struct_with_vtype

;

union union_with_vtype switch (boolean)

;
*/

};

The array_of_vtype cannot be mapped to Ada, neither can the
struct_with_vtype or union_with_vtype.

I propose a change to the mapping for valuetypes as follows:

" A valuetype shall be mapped to a package, or a nested package
when the valuetype is declared within a module. "

For clarity, here is the mapping that I propose for the above
example:

– file: my_module.ads
with CORBA.Value;

package my_module is

package vtype is

type Value_Ref is new CORBA.Value.Base with null record;

Null_Value : constant Value_Ref;

procedure Set_member
(Self : in Value_Ref;
To : in CORBA.Short);

function Get_member
(Self : in Value_Ref)
return CORBA.Short;

private
– elided
end vtype;

type array_of_vtype is array (0 .. 9) of vtype.Value_Ref;

end my_module;

The change of mapping also affects the naming rules for the
generated Value_Impl package because in Ada, it is not possible
to formulate child packages of nested packages.
I propose the following naming scheme for the Value_Impl
package:

The name of the Value_Impl package be formed from the name
of the value type mapped package with "_Value_Impl" appended.

Thus, the name of the Value_Impl package for the above example
would be: my_module.vtype_Value_Impl.

We understand the intent of this and agree that this is a problem. However, it is a
problem that is also present with the mapping of interface, e.g., we cannot map
the following IDL:
interface foo { };
typedef sequence<foo> fooSeq; with child packages. In actuality, the IDL compiler has to generate a "forward
reference" and then define a sequence of the forward reference as fooSeq.
This "flaw" in the mapping was recognized in the initial mapping effort and was
the subject of pretty extensive debate. The child package mapping of interface
had several other advantages: the ability to map the implementation package to
child packages of the interface, and the ability to use them along with forward
references to map the circular dependencies of interface (see the infamous
Chicken and Egg example.)
This flaw has been a problem in only a couple of cases over the 12+ years of the
current mapping (unfortunately the IR was one of them).
Thus, we are reluctant to make the change suggested by this issue. Granted it is
for valuetypes, not IDL interfaces, but consistency is important.
Disposition: Closed, No Change

Description:

Given the declarations

module m_a {
enum enum_a

;
};
module m_b

;

I believe the following is illegal:

const m_b::enum_b bconst = m_b::value_2;

Instead, to define such a constant in IDL, one needs to write

const m_b::enum_b bconst = m_a::value_2;

However, when mapping the typedefed enum to Ada, a derived type is
created.
The derived type implicitly creates visibility of the enum literals
in the new scope (in this example, module m_b).
Furthermore, enum_a and enum_b are not assignment-compatible in Ada.

A clarification should be added to the Ada mapping stating that
all mentions of scope prefixes at enum literals must be converted to
match the Ada rules.
Thus the above example

const m_b::enum_b bconst = m_a::value_2;

must be mapped as follows to Ada:

bconst : constant m_b.enum_b := m_b.value_2;

Accept the proposed resolution

Summary: It should be clarified that mentions of the type String in this
package refer to Standard.String. Being a child package of package
CORBA, the type String in CORBA.Bounded_Strings otherwise refers to
the type CORBA.String.

Accept the proposed clarifications.
• Add a parenthetical comments about package of String
• Specify name and scope for instantiation.

A CORBA implementation for Ada 95 must provide a typecode constant
for predefined type Object. This typecode constant is a function
"function TC_Object return CORBA.TypeCode.Object".

According to the standard declaration of package CORBA
(5.4 CORBA package), "function TC_Object is in CORBA.Object".

According to the standard declaration of package CORBA.Object
(5.2.2 Object), package CORBA.Object does not contain any such
declaration.

Thus we claim that there exist an inconsistency in the definition
of the location of function TC_Object.

The proposed resolution of this issue is to define a standard
location for funtion TC_Object. For consistency with user-defined
interfaces, we propose that a new standard package CORBA.Object.Helper
be defined, containing the declaration of function TC_Object.
We propose that the declaration of package CORBA be updated to
mention that function TC_Object is in CORBA.Object.Helper.

Accept as suggested. Add new section describing the CORBA.Object.Helper package

The dynamic invocation interface does not provide a way of raising
the exception potentially returned by a dynamic call. We thus propose to

add the following definitions in the CORBA package :

UnknownUserException : exception;
type UnknownUserException_Members is
new CORBA.IDL_Exception_Members with record
IDL_Exception : CORBA.Any;
end record;

procedure Get_Members
(From : Ada.Exceptions.Exception_Occurrence;
To : out UnknownUserException_Members);

corresponding to the following pseudoIDL :

exception UnknownUserException

;

Accept as suggested

Modification of the IDL specification of the CORBA.Object
package in order to include another way of creating Requests.
Addition of two new interfaces : ExceptionList and ContextList.
Modification of the CORBA.Request package to allow the user to
set the result type.

Description:
The mapping of the IDL specification of the CORBA.Object package in

Ada provides a single way of creating requests through the
create_request procedure. This procedure does not take into account the
context nor the exception possibly returned by the method invoked.
Therefore I suggest to add a new create_request procedure whose Ada
specification is :

procedure Create_Request
(Self : in CORBA.AbstractBase.Ref;
Ctx : in CORBA.Context.Ref;
Operation : in Identifier;
Arg_List : in CORBA.NVList.Ref;
Result : in out NamedValue;
Exc_List : in ExceptionList;
Ctxt_List : in ContextList;
Request : out CORBA.Request.Object;
Req_Flags : in Flags);

The specification of the types ExceptionList and ContextList are mapped
from the following pseudo Idl :

interface ExceptionList

;

pseudo interface ContextList

;

In addition, a method is missing in the package CORBA.Request to allow
the user to set the result type if he passed a null NamedValue at
creation of the request. I suggest to add the following method in
CORBA.Request :

package CORBA.request

;

Reject first suggestion: new create_request operation and attendant “list” types. Contexts
are not returned from operations in Replies, only provided in Requests and that parameter
is provided at request creation. Exceptions are not returned in Request objects for later
query; they are raised as the result of Invoke or Get_Result. The definitions of
ExceptionList and ContextList are not needed as a result.
Reject suggestion of Set_Return_Type. The result will be returned in a NamedValue, thus
the TypeCode of the result must be set when passed to Create_Request, or by Invoke or
Get_Result (by consulting the IR).
Disposition: Closed, no change

There is at this moment no way of creating an Any with a given
type but no value. This is however helpfull (if not needed) when
creating the Any passed (through a NamedValue) as the result parameter
of the CORBA.create_request method. I suggest to add a constructor for
Any objects with the following syntax :
package CORBA

;

Since there is no interface that allows the value of a type Any to be set independent of resetting
the TypeCode in the type Any, the value of this is not apparent.
Disposition: Closed, no change

page 1.14, end of page:
new PortableServer.Servant
should be
new PortableServer.ServantBase

p 4.22, beginning of section 4.9.1,
CORBA.Value_Forward
should be
CORBA.Value.Forward

Accept as suggested. However, searching has revealed other instances of the problem.
The following revised text reflects all changes for these name substitutions.

Description: section 4.5.5 of the ada mapping specifies that IDL
initializers have to be mapped into Ada functions. It reads "Thus they
will be primitive on the value reference type". For example,

// IDL
valuetype VT

is mapped into

// ada
package VT is
type Value_Ref is ...
function VT (l : in CORBA.Long) return Value_Ref;
end VT;

The fact that these functions be primitives implies that they have to
be overriden for each inheriting valuetype. This implies code
rewriting, with unprecise semantics: what should the semantic of the
overriding function be ?

Therefore, we suggest that the return type of the function be a
Value_Ref'Class, so that these functions are not primitives, and do
not have to be overriden.

Accept as suggested

Summary: At the end of section 1.17 of the 99-07-29 document,
there is:

type WTitle is new CORBA.Bounded_Wide_String_512.Bounded_String;

The wide string type should be Bounded_Wide_String if
the CORBA.Bounded_Wide_Strings package is to have the
same specification as
Ada.Strings.Wide_Bounded.Generic_Bounded_Length.

Accepted as suggested; this seems to have been a cut and paste error.

Summary: Delete the paragraph:

" This mapping supports the introduction of a subsystem name
that serves as a root virtual module for all declarations
in one or more files. When specified, subsystems create a
library package. "

The concept of subsystem is nowhere further explained.
I believe this might be a remainder from the time when the
#pragma Subsystem was supported.

Accept the proposed resolution; this is holdover from the removal of the pragma
Subsystem feature proposed initially. However, referencing text needs to be deleted in
both 1.3.1 and 1.9

Summary: Issue Type: Editorial

21.22.1 Mapping for Any Type - Handling Known Types
has:

function Get_Type (The_Any : in Any) return TypeCode.Ref;

The return type should be TypeCode.Object

Comment is correct. However, this appears to be a latent typographical error since the
correct type is used in the signature in section 5.4.

Summary: Has the Ada RTF considered the generation of a POA_<interface_name>
package for the Impl side mapping?

This is the approach taken by the C and C++ mappings, and has
the advantage of keeping the Impl package completely free of
code required by the ORB.

Discussion:
This approach was considered during the initial mapping development in 1995. It was
rejected because it would preclude inheritance of a servant type from a servant mapped
from a parent IDL interface, a use case considered much more important than the
advantage cited. The use of “tie” implementations can achieve the cited advantage.
Disposition: Closed, no change

Summary: This is a suggestion for consideration by the Ada Revision Task Force.

Experience with the IDL to Ada mapping (OMG Document 95-5-16)
convention for generating distinct types for each IDL typedef leads me to
suggest that generating a distinct Ada type for each IDL typedef results in
numerous types which might more clearly be generated as subtypes of a single
(family of) types.

The mapping of an IDL typedef to either a new Ada derived type or to an Ada subtype
was discussed extensively during the initial development of the Ada mapping in 1995. At
that time, it was recognized that the intended semantics of IDL fit Ada subtyping better
(for example, arrays and sequences of elements that were typedef’s of each other were
assumed to be the same type or at least freely convertible in common IDL usage), but the
desire to not “lose” the stronger typing of Ada lead most to opt for the stronger derived
typing mapping. That was the adopted mapping.
However, it has been suggested that the mapping choice, subtype or derived type, could
be effectively controlled by a pragma, an element that annotates but is not part of the IDL
syntax proper. The CORBA specification does require the handling of pragmas:
“Conforming IDL compilers may support additional non-standard pragmas, but must not
refuse to compile IDL source containing non-standard pragmas that are not understood by
the compiler.” This provision allows the introduction of Ada-specific pragmas without
breaking interoperability.
The revised text below introduces a pragma that overrides the default choice of mapping
of typedefs. It has also been suggested that the Ada-specific specification of range
constraints be introduced in the same way. Thus, the following IDL:
#pragma subtype Mylong
#pragma range MyLong 0 .. 100
typedef long MyLong;
maps to:
subtype MyLong is CORBA.Long range 0 .. 100; Of course, these pragmas could be separately applied to produce a subtype without range
constraint or range constrained derived type.