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 733: Ada mapping deficiency - orbos/97-09-26 Jira Issue ADA12-1
Issue 734: Ada mapping deficiency - orbos/97-09-26 (2) Jira Issue ADA12-2
Issue 735: Ada mapping deficiency - orbos/97-09-26 (3) Jira Issue ADA12-3
Issue 996: Ada mapping issue Jira Issue ADA12-4
Issue 1112: Ada issue: Type string in package CORBA spec Jira Issue ADA12-5
Issue 1320: Ada and the POA Jira Issue ADA12-6
Issue 1359: Ada Language Mapping: Section 23.5.5, Mapping for Interface Jira Issue ADA12-7
Issue 1387: IDL to Ada Mapping: Ada package CORBA.Object (01) Jira Issue ADA12-8
Issue 1388: Mapping of IDL to Ada: Ada package CORBA.Object Jira Issue ADA12-9
Issue 1504: Chapter 23.2.7 of CORBA 2.2, IDL to Ada Mapping ( pragma Subsystem) Jira Issue ADA12-10
Issue 1702: Nil object reference (CORBA v. 2.2) Jira Issue ADA12-11
Issue 1806: Mapping of structure, union or exception types Jira Issue ADA12-12
Issue 1807: Mapping of sequesnce types Jira Issue ADA12-13
Issue 1808: Mapping for typedef Jira Issue ADA12-14
Issue 1809: Mapping for standard exceptions Jira Issue ADA12-15
Issue 1810: NamedValue in 23.6.1 Jira Issue ADA12-16
Issue 1811: TypeCode in 23.6.6 Jira Issue ADA12-17
Issue 1812: list_initial_services and resolve_initial_references are missing Jira Issue ADA12-18
Issue 1813: 23.6.8 Object circularities Jira Issue ADA12-19
Issue 1814: Parameter Result in Createrequest cannot be "in out NamedValue Jira Issue ADA12-20
Issue 1818: Mapping of Operations (23.5.9) "Returns" parameter Jira Issue ADA12-21
Issue 1846: 23.5.5 Mapping for Interfaces (Client-Side Specific) Jira Issue ADA12-22
Issue 1856: 23.5.5 Mapping for Interfaces (Client-Side Specific) Jira Issue ADA12-23
Issue 1896: 23.8.1 Package CORBA Jira Issue ADA12-24
Issue 2036: Error in section 21.3.3 Jira Issue ADA12-25
Issue 2043: Section 21.8.9: Examples Jira Issue ADA12-26
Issue 2044: The name of the mapped type shall be "Fixed_" prepended Jira Issue ADA12-27
Issue 2095: Suggestion on mapping the OMG IDL language to Ada Jira Issue ADA13-1
Issue 2209: Method for converting an Object to a Ref Jira Issue ADA12-28
Issue 2262: Impl methods should be dispatchable Jira Issue ADA12-29
Issue 2458: Name and scope of instantiation of CORBA.Sequences.{Un}Bounded Jira Issue ADA12-30
Issue 2459: Mapping of operation parameters of same interface type. Jira Issue ADA12-31
Issue 2612: Mapping for String Types - Bounded Strings Jira Issue ADA13-2
Issue 2632: ptc/99-02-02 page 21-5 Server Side, common root type CORBA.Object.Objec Jira Issue ADA12-32
Issue 2649: ptc/99-02-02: Impl side mapping and the POA Jira Issue ADA13-3
Issue 2656: ptc/99-02-02: 21.22.1 Handling Known Types Jira Issue ADA13-4
Issue 2657: 21.2.7 Mapping Summary - Names and Scoping Jira Issue ADA13-5
Issue 2891: CORBA 2.3 Ada, Mapping for Wide String Types Jira Issue ADA13-6
Issue 3627: Inconsistency in the definition of implementation object types. Jira Issue ADA13-7
Issue 3701: narrowing of valuetypes Jira Issue ADA13-8
Issue 3702: tagged types mapped from abstract interfaces Jira Issue ADA13-9
Issue 3703: mapping of IDL factories (initializers) for valuetypes Jira Issue ADA13-10
Issue 3704: ada language mapping specification -- TYPOS Jira Issue ADA13-11
Issue 3705: Addition of a constructor for "empty" Any objects. Jira Issue ADA13-12
Issue 3706: Mapping of CORBA.Request in Ada Jira Issue ADA13-13
Issue 3722: declaration of an UnknownUserException Jira Issue ADA13-14
Issue 3736: Inconsistency in the definition of the location of TC_Object Jira Issue ADA13-15
Issue 5682: Insecurity about literals of typedefed enums Jira Issue ADA13-16
Issue 5768: Concern about the mapping of valuetypes to Ada Jira Issue ADA13-17
Issue 5773: IDL to Ada mapping for valuetypes Jira Issue ADA13-18
Issue 5859: Mapping of reopened modules to Ada Jira Issue ADA13-19
Issue 12426: Table 2-1 in section 2.2.4 Jira Issue ADA13-20
Issue 12752: Interface/valuetype forward declarations and Ada2005 Jira Issue ADA13-21

Issue 733: Ada mapping deficiency - orbos/97-09-26 (ada-rtf)

Summary: Inconsistencies between sections 21.2.1 and 21.7.3. The change from CORBA.Object.Object to CORBA.Implementation_Defined.Object is not reflected in 21.2.1 and 21.7.3. The private section still contains CORBA.Objetc.Object. The context clause  "with CORBA.object" should be changed to "with CORBA.Implementation_Defined" 

 closed issue

Summary: The pseude-object specifications in the main body of the text do not match with the appendices. There are differences between specs and appendices include NVlist, Context, TypeCode, BOA, and Object 

 closed issue

Summary: Inconsistencies in section 21.5.8 (standard exceptions) and Appendix A1 (package CORBA): Changes to standard exceptions section have not been reflected in Appendix 1A (System_Exception_Members, exception members type) The example exception members type is referred to as Unknown_Members and Unknown_Exception_Members. It is not clear how type Unknown_Members is used 

 received issue

Summary: Please refer to Chapter 22 of ptc/98-01-04  and provide Ada language   mappings for the operations that have been added to CORBA::Object and   CORBA::ORB from Security Service in Core Revn 2.2 and 2.3.   Ada Mapping issue 

Summary: I have a suggestion regarding the current (CORBA version 2.2) IDL to Ada   >mapping which concerns the type String in the package CORBA spec.    >Here is a diff of the addition that I propose:   >   >*** corba.ads.orig	Mon Mar  2 09:38:27 1998   >--- corba.ads	Wed Mar 25 08:35:28 1998   >***************   >*** 29,34 ****   >--- 29,37 ----   >     type    Octet          is new Interfaces.Unsigned_8;   >     type    String         is new Ada.Strings.Unbounded.Unbounded_String;   >     >+    Null_Unbounded_String : constant String   >+                       := String   >(Ada.Strings.Unbounded.Null_Unbounded_String);   >+    >     -- Exceptions   >     >     type IDL_Exception_Members is abstract tagged null record;   >   >   >The lack of the Null_Unbounded_String constant in the current CORBA spec    >means it is cumbersome to compare a CORBA.String against the    >Ada.Strings.Unbounded.Null_Unbounded_String, as such comparison requires a    >type conversion.    

Summary: The Ada language binding has not been updated to deal with the   deletion of the BOA and the introduction of the native type for the POA.    

 received issue

Summary: Ada Language Mapping:  Section 23.5.5, �Mapping for Interfaces�      **The following text is added to the Ada language mapping within section   23.5.5 at the end of the subsection titled, �Narrowing Object   References�.**      Narrowing an object reference can require a remote invocation (to either   the target object or to an Interface Repository) to verify the   relationship between the actual object and the desired narrow   interface.  For cases where the application programmer wishes to avoid   the possibility of this remote invocation, conforming implementations   must provide a primitive subprogram in each interface package to perform   an unchecked narrow operation.   Each interface mapping shall include a function with specification:      function Unchecked_To_Ref(The_Ref : in CORBA.Object.Ref�CLASS) return   Ref;      Regardless of whether or not The_Ref is known to support the desired   interface, the provided implementation returns a narrowed reference.       

Summary: I have a few suggestions concerning the Mapping of OMG IDL to    Ada (chapter 23 of the CORBA V2.2 spec.)      The C++ mapping in the same document among other defines a class   Object (see chapter 20.32.2). This class provides a number of   methods that the equivalent Ada package CORBA.Object (chapter   23.8.8) does not.      My first suggestion is to supply the verbatim text of the IDL   interface Object on which the Ada package CORBA.Object is   based. (This is chapter 20.32.1 in the C++ mapping.)    

Summary: My further suggestion is to adopt a single IDL specification as    the basis for both the C++ and the Ada language mappings for the   interface Object (and other predefined interfaces). This is in   the interest of compatibility of programming interfaces.      In particular, I find the following methods lacking in the Ada   package CORBA.Object that are present in the C++ class Object:    

Summary:  Chapter 23.2.7 of the CORBA v2.2 Mapping of OMG IDL to Ada   mentions:      " Files (actually inclusion streams) create a package to contain the     "bare" definitions defined in IDL"s global scope. The package name     is formed from the concatenation of the file name and _IDL_File.    "      In the absence of a pragma Subsystem, this solution is felt to be   unsatisfying. 

Summary: Section 20.3.5 of the OMG IDL to C++ Mapping states:      " The mapping for an interface defines a static member function      named _nil that returns a nil object reference of that interface      type [...] "      Although the section "Object Reference Operations" in the OMG IDL    to Ada Mapping chapter 23.5.5 defines a function        function Is_Nil (Self : Ref) return Boolean;      the mapping does not define a Nil operation.       

Summary: In the mapping of structure, union or exception types, the same    complex_declarator component may occur in two or more structure    definitions, the name of the generated types will collide in the    proposed mapping. It would be wise to prepend the name of the    enclosing structure:      mapping of structure, union or exception types 

 Close with no change:

Summary: The mapping of the sequence types does not corresponds to the    definition of the packages defined in 23.8.12, 23.8.13 and 23.8.14 :   - with clauses are not correct   - there is no array type as generic formal parameter       

 Addressed by previousRTF:

Summary: In the mapping for typedef, if the ancestor type is the Object type    or an interface, then subtyping should occur in place of derivation.   This would avoid several difficulties either in the generated code    and in the application code.    

Summary: In the mapping of standard exceptions, ex_body maps to    System_Exception_Members which is defined as Ex_Body in the Corba    package.    

Summary: In 23.6.1 NamedValue, the len component is useless and meaningless in    Ada.    

 received issue

Summary: In 23.6.6 TypeCode, the package TypeCode should correspond to the    pseudo-IDL given in the CORBA 2 specification.    

 received issue

Summary: In 23.6.7 ORB, the operations list_initial_services and    resolve_initial_references are missing. They need an ORB object to    apply to.   ORB_init is nowhere defined but it could be added to Corba.Orb.    

Summary: In 23.6.8 Object,   - there are circularities as Corba.ImplementationDef.Ref and    Corba.InterfaceDef.Ref are derived from Corba.Object.Ref. One    solution to these circularities is to replace these types by    Corba.Object.Ref"class.    

 Accept with Modification:

Summary: - The parameter Result in CreateRequest cannot be an "in out    NamedValue" as the result will be unreachable once the operation has    completed. Instead, it should be of an access type to NamedValue.    

Summary: Section 23.5.9, 2nd paragraph, states that        [...] The non-void result, if any, is returned via an added      argument with name "Returns".      The word "added" would seem to imply that the Returns parameter    shall appear at the end of the parameter list. However, the    standard should be more explicit about the required parameter    position of the Returns parameter.       

Summary: 23.5.5 Mapping for Interfaces (Client-Side Specific)      The section "Nil Object Reference" states:     [...] This mapping relies on the Is_Nil function to detect      uninitialized object references, and does require or allow      definition of a Nil constant.      Could it be that this should read: "... does NOT require ..." ?    

Summary: 23.5.5 Mapping for Interfaces (Client-Side Specific)      The section "Object Reference Operations" has some lines in    typewriter font:        function Is_Nil(Self : Ref) return Boolean;        procedure Release(Self : Ref"CLASS);      I believe these lines should instead be:        function Is_Nil(Self : Ref"CLASS) return Boolean;        procedure Release(Self : in out Ref"CLASS);      Also, the Release operation is missing from 23.6.8 (Object)    and lacking the "CLASS attribute in 23.8.8 (package CORBA.Object)       

Summary: I propose the addition of two functions to the  package CORBA:  function To_CORBA_String (Source :  Standard.String) return CORBA.String;   function To_Standard_String (Source :  CORBA.String) return Standard.String;  In my opinion, the frequency with which these  conversion functions are    needed when dealing with the type CORBA.String  justify their inclusion    in the CORBA package. 

Summary: Ada"s "not" is not specified for signed integers.      If the table entry is to be read as "for signed integers, use the expression   -(value-1)", then it would be more obvious, if the check sign appeared in   the second line (where the expression is), not in the first line (where the   not operator is).      At least a comment seems appropriate.    

Summary: Section 21.8.9:      Example Chicken.idl:      Freezing rules (ARM 13.14) cause the packages Egg and Chicken to be illegal.   The declaration of     function To_Ref (The_Ref : in Corba.Object.Ref"Class) return Ref;   has to occur before the declaration of       package Convert is new Egg/Chicken_Forward.Convert (Ref);   ARM 13.14(5,16).         Example Tank:      package Tank is        type Ref is new Vehicle.Ref with record       Mixin: Asset.Ref;     end record;      If I"m not missing something fundamental, this mixin is needed to allow   reference to Asset.Op1/2.    

 in Corba.Object.Ref"Class) return Ref; 

Summary: Section 21.10:      The name of the mapped type shall be "Fixed_" prepended [rather than   appended] to the IDL specified number of digits, ...    

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: The Ada mapping lacks a method for converting an    implementation side Object to the corresponding    proxy side Ref. The C++ mapping defines a method,    _this(), for this purpose (see CORBA V2.2 chapter    20.34.2.)      I propose the addition in the code generated for an    interface A, in package A.Impl:         function To_Ref (Self : access Object) return Ref;    

Summary: I suggest that the IDL to Ada mapping standard specifically    mention that Impl side methods be dispatching. In order to    achieve this, the Impl package spec generated for an    interface A should contain the marked declaration:      with POA_A;   package A.Impl is      type Object is new POA_A.Object with private;      -------- ADDITION :      type Object_Access is access all Object"Class;      -------- END OF ADDITION         -- example method:      procedure Meth (Self : access Object);      end A.Impl;    

Summary: CORBA V2.2 section 23.5.6, Mapping for Sequence Types,    states that      " The name and scope of the instantiation     [of CORBA.Sequences.Bounded or CORBA.Sequences.Unbounded]     is left implementation defined. "      However, the drawing.idl mapping example in the same section    suggests that      1) the name of the instantiation be the simple_type_spec       with "IDL_SEQUENCE_" prepended      2) the instantiation be located within the same scope as       the corresponding IDL sequence type declaration.      (This could be expanded to state that if the sequence       type declaration appears at the IDL file scope level,       then the instantation shall appear within the       synthesized IDL_FILE_ package.)    

Summary: It is a natural consequence of the Ada language rules that an operation   parameter of the same interface type, other than the implied parameter,   must be mapped to a class-wide reference type. The Ada language rules   disallow two controlling parameters, and the first added Ref parameter must   be the controlling parameter. So, for an operation that has an implicit   parameter of the enclosing interface, a special mapping rule is needed so   that the operation is not primitive on that parameter.     

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: The Ada RTF submission for the CORBA 2.4 Ada Mapping,    document ptc/99-02-02, under section 21.2.1 Interfaces    and Tagged Types, Server Side, states      " The package contains a declaration for the Object      type, derived from the parent interface"s object type      or from a common root, CORBA.Object.Object, [...] "      The common root type should be PortableServer.Servant_Base.       

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

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

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

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

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 {     Chicken hatch();  };  interface Chicken {     Egg lay();  };      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;