Issues for Ada 2003 Revision Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 2095: Suggestion on mapping the OMG IDL language to Ada
Issue 2612: Mapping for String Types - Bounded Strings
Issue 2649: ptc/99-02-02: Impl side mapping and the POA
Issue 2656: ptc/99-02-02: 21.22.1 Handling Known Types
Issue 2657: 21.2.7 Mapping Summary - Names and Scoping
Issue 2891: CORBA 2.3 Ada, Mapping for Wide String Types
Issue 3627: Inconsistency in the definition of implementation object types.
Issue 3639: The Ada mapping of the Interface Repository.
Issue 3701: narrowing of valuetypes
Issue 3702: tagged types mapped from abstract interfaces
Issue 3703: mapping of IDL factories (initializers) for valuetypes
Issue 3704: ada language mapping specification -- TYPOS
Issue 3705: Addition of a constructor for "empty" Any objects.
Issue 3706: Mapping of CORBA.Request in Ada
Issue 3722: declaration of an UnknownUserException
Issue 3736: Inconsistency in the definition of the location of TC_Object
Issue 5682: Insecurity about literals of typedefed enums
Issue 5768: Concern about the mapping of valuetypes to Ada
Issue 5773: IDL to Ada mapping for valuetypes
Issue 5859: Mapping of reopened modules to Ada
Issue 6344: Ada Mapping of Sequences Too Heavy
Issue 12426: Table 2-1 in section 2.2.4

Issue 2095: Suggestion on mapping the OMG IDL language to Ada (ada-rtf)

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.
 

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.
 

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.
 

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
 

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.
 
 

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.
 

	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;"

Summary: Standardisation of the declaration of the Ada units mapping the
        Interface Repository Specification

Description:
	The mapping of the IDL specification of the IR in Ada implies
	the creation of forward declarations of interfaces (the
	"IDLType" interface for instance). Those should be mapped in
	Ada to subpackages of CORBA using the CORBA.Forward
	package. This leads to a circular dependency in the new CORBA
	package.

Proposed solution:
        These interfaces cannot be mapped as instanciations of
        CORBA.Forward that are child packages of CORBA, because
        they are subsequently used in the definition of record
        types in the declaration of CORBA (eg interface IDLType
        as a component of StructMember).

	We therefore propose the following addition to the standard
        mapping definition for module CORBA:

        "The types defined within module CORBA by the Interface
        Repository Specification (formal/99-10-07, p10-56 to 10-68),
        except the TypeCode and ORB interfaces, shall be mapped to a
        (child) library package CORBA.Repository_Root." 

	A comment at the end of the declaration of the package CORBA
	implies that this is probably the intent of the author to
	provide such a standard child unit. 

	We further propose that the contents of the declaration of
	child package CORBA.Repository_Root be standardized. We will
	provide a proposed specification on request.

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.

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)

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 {
factory create(in long l);
}

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.

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

 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 {
  function Get_Empty_Any (Tc : in TypeCode.Object) return Any;
};

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 {
  readonly attribute unsigned long count;
  void add(in TypeCode exc);
  TypeCode item(in unsigned long index) raises(Bounds);
  void remove(in unsigned long index) raises(Bounds);
};

pseudo interface ContextList {
  readonly attribute unsigned long count;
  void add(in string ctxt);
  string item(in unsigned long index) raises(Bounds);
  void remove(in unsigned long index) raises(Bounds);
};

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 {
  procedure Set_Return_Type (CORBA.TypeCode.Object Tc);
};

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 { any _Exception; };

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.

Description:


Given the declarations


 module m_a {
   enum enum_a { value_1, value_2 };
 };
 module m_b {
   typedef m_a::enum_a enum_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;

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 {
      public short member;
   };
 
   typedef vtype array_of_vtype[10];
 
/* Further sources of problems:
 *
   struct struct_with_vtype {
      vtype smember;
   };
 
   union union_with_vtype switch (boolean) {
      case true:
         vtype umember;
   };
 */
 
};
 
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.

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?

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

The current mapping of IDL sequences to the Ada language results in a instantiation of a defined generic package. However, each instantiation results in roughly 150K of additional object code. This is excessive for embedded systems, especially if multiple sequences are used in an application. A lightweight alternative, such as the mapping defined for C++, should be defined.

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.)