Issues for Ada 2003 Revision Task Force

To comment on any of these issues, send email to ada-rtf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

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 3639: The Ada mapping of the Interface Repository. Jira Issue ADA-1
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 6344: Ada Mapping of Sequences Too Heavy Jira Issue ADA-2
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)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
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"

Resolution: close with no change
Revised Text: Close with No Change. These problems have been obsoleted by the resolution of
Actions taken:
October 3, 1997: received issue
June 4, 1999: closed issue

Discussion:
 closed issue


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

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
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

Resolution: Accepted.close isse
Revised Text: Accepted.
Actions taken:
October 3, 1997: received issue
June 4, 1999: closed issue

Discussion:
 closed issue


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

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
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

Resolution: Accepted, close issue
Revised Text: Accept.
Actions taken:
October 3, 1997: received issue
June 4, 1999: closed issue

Discussion:
 received issue


Issue 996: Ada mapping issue (ada-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
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

Resolution: :Object and
Revised Text: :ORB from Security Service in Core Revn 2.2 and 2.3.
Actions taken:
March 9, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1112: Ada issue: Type string in package CORBA spec (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
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.
 

Resolution:
Revised Text:
Actions taken:
March 26, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1320: Ada and the POA (ada-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
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.
 

Resolution:
Revised Text:
Actions taken:
May 13, 1998: received issue
June 4, 1999: closed issue

Discussion:
 received issue


Issue 1359: Ada Language Mapping: Section 23.5.5, Mapping for Interface (ada-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
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.
 
 

Resolution:
Revised Text:
Actions taken:
May 15, 1998: received issue
December 2, 2002: closed issue

Discussion:


Issue 1387: IDL to Ada Mapping: Ada package CORBA.Object (01) (ada-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
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.)
 

Resolution:
Revised Text:
Actions taken:
May 19, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1388: Mapping of IDL to Ada: Ada package CORBA.Object (ada-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
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:
 

Resolution:
Revised Text:
Actions taken:
May 19, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1504: Chapter 23.2.7 of CORBA 2.2, IDL to Ada Mapping ( pragma Subsystem) (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
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.

Resolution:
Revised Text:
Actions taken:
June 4, 1998: received issue
June 4, 1998: issue moved from orb_revision to the ada-rtf
December 2, 2002: closed issue

Discussion:


Issue 1702: Nil object reference (CORBA v. 2.2) (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
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.
 
 

Resolution:
Revised Text:
Actions taken:
July 20, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1806: Mapping of structure, union or exception types (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
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

Resolution:
Revised Text:
Actions taken:
August 13, 1998: received issue
June 4, 1999: closed issue

Discussion:
 Close with no change:


Issue 1807: Mapping of sequesnce types (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
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
 
 

Resolution:
Revised Text:
Actions taken:
August 13, 1998: received issue
June 4, 1999: closed issue

Discussion:
 Addressed by previousRTF:


Issue 1808: Mapping for typedef (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
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.
 

Resolution:
Revised Text:
Actions taken:
August 13, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1809: Mapping for standard exceptions (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
Summary: In the mapping of standard exceptions, ex_body maps to 
 System_Exception_Members which is defined as Ex_Body in the Corba 
 package.
 

Resolution:
Revised Text:
Actions taken:
August 13, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1810: NamedValue in 23.6.1 (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
Summary: In 23.6.1 NamedValue, the len component is useless and meaningless in 
 Ada.
 

Resolution:
Revised Text:
Actions taken:
August 13, 1998: received issue
June 4, 1999: closed issue

Discussion:
 received issue


Issue 1811: TypeCode in 23.6.6 (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
Summary: In 23.6.6 TypeCode, the package TypeCode should correspond to the 
 pseudo-IDL given in the CORBA 2 specification.
 

Resolution:
Revised Text:
Actions taken:
August 13, 1998: received issue
June 4, 1999: closed issue

Discussion:
 received issue


Issue 1812: list_initial_services and resolve_initial_references are missing (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
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.
 

Resolution:
Revised Text:
Actions taken:
August 13, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1813: 23.6.8 Object circularities (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
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.
 

Resolution:
Revised Text:
Actions taken:
August 13, 1998: received issue
June 4, 1999: closed issue

Discussion:
 Accept with Modification:


Issue 1814: Parameter Result in Createrequest cannot be "in out NamedValue (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
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.
 

Resolution:
Revised Text:
Actions taken:
August 13, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1818: Mapping of Operations (23.5.9) "Returns" parameter (ada-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity:
Summary:
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.
 
 

Resolution:
Revised Text:
Actions taken:
August 17, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1846: 23.5.5 Mapping for Interfaces (Client-Side Specific) (ada-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity:
Summary:
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 ..." ?
 

Resolution:
Revised Text:
Actions taken:
August 20, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1856: 23.5.5 Mapping for Interfaces (Client-Side Specific) (ada-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity:
Summary:
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)
 
 

Resolution:
Revised Text:
Actions taken:
August 24, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1896: 23.8.1 Package CORBA (ada-rtf)

Click
here for this issue's archive.
Nature: Enhancement
Severity:
Summary:
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.

Resolution: CORBA.String) return Standard.String; In my opinion, the frequency with which these conversion f
Revised Text:
Actions taken:
August 28, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 2036: Error in section 21.3.3 (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
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.
 

Resolution:
Revised Text:
Actions taken:
October 5, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 2043: Section 21.8.9: Examples (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
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.
 

Resolution:
Revised Text:
Actions taken:
October 6, 1998: received issue
June 4, 1999: closed issue

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


Issue 2044: The name of the mapped type shall be "Fixed_" prepended (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
Summary: Section 21.10:
 
 The name of the mapped type shall be "Fixed_" prepended [rather than
 appended] to the IDL specified number of digits, ...
 

Resolution:
Revised Text:
Actions taken:
October 6, 1998: received issue
June 4, 1999: closed issue

Discussion:


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

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
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.
 

Resolution: 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.
Revised Text: Change the last sentence of the first paragraph under section 3.13 to read: “An IDL typedef maps to an Ada derived type by default, or to an Ada subtype (see section 3.13.1).” Insert a new sub-section 3.13.1 after the first paragraph of the current section 3.13: 3.13.1 Controlling pragmas The default choice of mapping of a typedef may be overridden or reinforced by a pragma that appears before the typedef clause in the IDL in the same scope. The syntax of the pragmas are: #pragma subtype <name> #pragma derived <name> where <name> is a simple identifier presumed to be type name that will be typedef’d in the same scope. It is an error to specify multiple subtype pragmas, multiple derived pragmas, or both subtype and derived pragmas for the same type. It is an error to specify a subtype pragma or a derived pragma after the corresponding type has been defined in IDL. It is an error to specify a subtype or a derived pragma for a type named in an array declarator. A range constraint may be introduced to the result of the mapping of a typedef’d IDL type through a range pragma. The BNF syntax of the pragma is: <range_pragma> ::= #pragma range <scoped_name> <range_constraint> <range_constraint> ::= [<const_exp>] [.. <const_exp>] | <string_literal> where <scoped_name> is an type name that will be typedef’d in the same scope (for a const_type), and <range_constraint> specifies the range. If the range_constraint is a string_literal ,i.e., enclosed by quotations, the literal express is assumed to be valid in the target language and will be mapped lexically. Otherwise, each const_exp will be interpreted as if it were an IDL constant expression. The first const_exp, if any, specifies the minimum of the range for the subtype. If missing, the minimum of the range shall be the minimum of the unconstrained type. The second const_exp (i.e., the one after the “..”) specifies the maximum of the range of the subtype. If missing, the maximum of the range shall be the maximum of the unconstrained type. It is an error to specify mulitple range pragmas for the same type. It is an error to specify a range pragma for a type named in an array declarator. It is an error to specify a range for a type that is not a <const_type>. It is an error to specify a range that is greater than the range of the parent type. Insert a new sub-section header after the inserted text above: 3.13.2 Mapping Substitute the following two paragraphs for the third (3rd) paragraph of the current section 3.13: Each simple declarator for a reference type, that is, a type in CORBA.Object.Ref'CLASS, shall be mapped to a subtype declaration. Each simple declarator for a non-reference type that is cited in a subtype pragma shall be mapped to a subtype declaration. Each simple declarator for a non-reference type that is not cited in a subtype pragma shall be mapped to a derived type declaration. The type or subtype name shall be the identifier provided in the simple declarator. The type definition shall be the mapping of the typespec, as specified elsewhere in this section. If the type or subtype name is cited in a range pragma the mapped typespec shall include an Ada range constraint clause. If the IDL range_constraint is a string literal, the range constraint shall be ìrange <string_literal>î. Otherwise, the minimum for the range specification shall be mapped from the IDL minimum const_exp, if any, or the 'first of the mapped type, if no minimum was defined. The maximum for the range specification shall be mapped from the IDL maximum const_exp, if any, or the 'last of the mapped type, if no maximum was defined. Add the following to the example IDL typedef’s: #pragma subtype Mylong #pragma range MyLong 0 .. 100 typedef long MyLong; #pragma range NewLong “MyLong’range” typedef long NewLong; const long MinNatural = 0; #pragma range Natural MinNatural typedef long Natural; Add the following to the example mappings: subtype MyLong is CORBA.Long range 0 .. 100; type NewLong is new CORBA.Long range MyLong’range; MinNatural : constant CORBA.Long = 0; type Natural is new CORBA.Long range MinNatural .. CORBA.Long’last; Disposition: Resolved
Actions taken:
October 19, 1998: received issue
January 12, 2010: closed issue

Discussion:


Issue 2209: Method for converting an Object to a Ref (ada-rtf)

Click
here for this issue's archive.
Nature: Enhancement
Severity:
Summary:
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;
 

Resolution:
Revised Text:
Actions taken:
November 13, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 2262: Impl methods should be dispatchable (ada-rtf)

Click
here for this issue's archive.
Nature: Enhancement
Severity:
Summary:
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;
 

Resolution:
Revised Text:
Actions taken:
December 16, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 2458: Name and scope of instantiation of CORBA.Sequences.{Un}Bounded (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
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.)
 

Resolution:
Revised Text:
Actions taken:
February 19, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2459: Mapping of operation parameters of same interface type. (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
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. 
 

Resolution:
Revised Text:
Actions taken:
February 19, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2612: Mapping for String Types - Bounded Strings (ada-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity:
Summary:
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.
 

Resolution: Accept the proposed clarifications. • Add a parenthetical comments about package of String • Specify name and scope for instantiation.
Revised Text: In section 3.9, in the paragraph: “Conforming implementations shall provide a CORBA.Bounded_Strings package with the same specification and semantics as Ada.Strings.Bounded.Generic_Bounded_Length.” Add a parenthetical clarification: “Conforming implementations shall provide a CORBA.Bounded_Strings package with the same specification and semantics as Ada.Strings.Bounded.Generic_Bounded_Length. (All references to String, as opposed to Bounded_String, in the specification of Generic_Bounded_Length, must be changed to Standard.String to distinguish from the CORBA.String type.)” Change the following paragraph: “The CORBA.Bounded_Strings package has a generic formal parameter “Max” declared as type Positive and establishes the maximum length of the bounded string at instantiation. A generic instantiation of the package shall be created using the bound for the IDL string as the associated parameter. The name and scope of the instantiation is left implementation defined.” to: “The CORBA.Bounded_Strings package has a generic formal parameter “Max” declared as type Positive and establishes the maximum length of the bounded string at instantiation. A generic instantiation of the package shall be created using the bound for the IDL string as the associated parameter. The name of the instantiation shall be “Bounded_String_” with the length appended, and the instantiation shall be a child package of the CORBA package.” In the example following, change “may map to” to “shall map to”. Similar changes are required in section 3.10. In the paragraph: “Conforming implementations shall provide a CORBA.Bounded_Wide_Strings package with the same specification and semantics as Ada.Strings.Wide_Bounded.Generic_Bounded_Length.” Add a parenthetical clarification: “Conforming implementations shall provide a CORBA.Bounded_Wide_Strings package with the same specification and semantics as Ada.Strings.Wide_Bounded.Generic_Bounded_Length. (All references to Wide_String, as opposed to Bounded_Wide_String, in the specification of Generic_Bounded_Length, must be changed to Standard.Wide_String to distinguish from the CORBA.Wide_String type.)” Change the following paragraph: “The CORBA.Bounded_Wide_Strings package has a generic formal parameter “Max” declared as type Positive and establishes the maximum length of the bounded string at instantiation. A generic instantiation of the package shall be created using the bound for the IDL string as the associated parameter. The name and scope of the instantiation is left implementation defined.” to: “The CORBA.Bounded_Strings package has a generic formal parameter “Max” declared as type Positive and establishes the maximum length of the bounded string at instantiation. A generic instantiation of the package shall be created using the bound for the IDL string as the associated parameter. The name of the instantiation shall be “Bounded_String_” with the length appended, and the instantiation shall be a child package of the CORBA package.” In the example following, change “may map to” to “shall map to”. Disposition: Resolved
Actions taken:
April 26, 1999: received issue
January 12, 2010: closed issue

Discussion:


Issue 2632: ptc/99-02-02 page 21-5 Server Side, common root type CORBA.Object.Objec (ada-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
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.
 
 

Resolution:
Revised Text:
Actions taken:
May 5, 1999: received issue
December 2, 2002: closed issue

Discussion:


Issue 2649: ptc/99-02-02: Impl side mapping and the POA (ada-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
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.
 

Resolution: 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
Revised Text:
Actions taken:
May 10, 1999: received issue
January 12, 2010: closed issue

Discussion:


Issue 2656: ptc/99-02-02: 21.22.1 Handling Known Types (ada-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
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
 

Resolution: 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.
Revised Text: In section 3.15.1 change: function Get_Type(The_Any : in Any) return TypeCode.Ref; to: function Get_Type(The_Any : in Any) return TypeCode.Object;
Actions taken:
May 18, 1999: received issue
January 12, 2010: closed issue

Discussion:


Issue 2657: 21.2.7 Mapping Summary - Names and Scoping (ada-rtf)

Click
here for this issue's archive.
Source: Airbus Group (Mr. Oliver M. Kellogg, oliver.kellogg(at)cassidian.com)
Nature: Uncategorized Issue
Severity:
Summary:
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.
 
 

Resolution: 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
Revised Text: Delete the following text from the first paragraph in section 1.3.1: “(including a subsystem “virtual scope”)” Delete the second paragraph from Section 1.9: “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.” Disposition: Resolved
Actions taken:
May 18, 1999: received issue
January 12, 2010: closed issue

Discussion:


Issue 2891: CORBA 2.3 Ada, Mapping for Wide String Types (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
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.
 

Resolution: Accepted as suggested; this seems to have been a cut and paste error.
Revised Text: Change the second to last paragraph in section 3.10: “type WTitle is new CORBA.Bounded_Wide_String_512.Bounded_String;” to: “type WTitle is new CORBA.Bounded_Wide_String_512.Bounded_Wide_String;” Disposition: Resolved Ada RTF 1.3 Disposition: Resolved OMG Issue No: 2891 Document
Actions taken:
September 15, 1999: received issue
January 12, 2010: closed issue

Discussion:


Issue 3627: Inconsistency in the definition of implementation object types. (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
	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;"

Resolution: Accepted as suggested. However, the definition of CORBA.Local.Object should also be similarly changed
Revised Text: In 5.2.4 (formerly 5.2.3) "CORBA.Value.Base", replace the definition of type Impl_Base with "type Impl_Base is abstract new CORBA.Impl.Object with private;" In 5.2.6 (formerly 5.2.5) "LocalObject", replace the definition of type Object with "type Object is abstract new CORBA.Impl.Object with private;" In 5.2.7 (formerly 5.2.6) "PortableServer.Servant_Base", replace the definition of type Servant_Base with "type Servant_Base is abstract new CORBA.Impl.Object with private;"
Actions taken:
May 19, 2000: received issue
January 12, 2010: closed issue

Issue 3639: The Ada mapping of the Interface Repository. (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
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.

Resolution:
Revised Text:
Actions taken:
May 23, 2000: received issue

Discussion:
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.
Discussion:
Deferred due to lack of time.
Disposition: Deferred


Issue 3701: narrowing of valuetypes (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
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.

Resolution: 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.
Revised Text: Add the following as a third bullet in number 3 under section 1.10.2.1: • A narrowing function capable of converting an instance of another Value_Ref type to the target Value_Ref type, if the input Value_Ref refers to an instance of an implementation of the target Value_Ref type or of a more derived type. Replace the fourth paragraph of Section 1.10.2.2: “In order to support widening from concrete value types that may inherit from the abstract value type, the .Helper child package will contain a To_Abstract_Value_Ref function that will widen a reference to any concrete or abstract value that inherits from it to a valid reference of the abstract type. ” with “In order to support widening from other value types that may inherit from the value type, the .Helper child package will contain a To_Value_Ref function that will widen a reference to any concrete or abstract value that inherits from it to a valid reference of the abstract type. ” Insert the following as new Section 4.6.4: 4.6.4 Widening and Narrowing ValueTypes Valuetypes may be related by inheritance. Any abstract valuetype may have any number of abstract parent valuetypes. Any stateful valuetype may have one stateful parent valuetype in addition to any number of abstract parent valuetypes. In order to support type-safe conversion among valuetypes, the helper package will contain a conversion function. The value helper package for each valuetype shall contain the following function: function To_Value_Ref (From : in CORBA.Value.Base'Class) return Value_Ref; The To_Value_Ref function shall return a valuetype of the Value_Ref type if either: • (widening) Any of the parents of the type of From is Value_Ref • (narrowing) The implementation instance referred to by From is either • null or • an implementation of a valuetype that is either Value_Ref or is derived from Value_Ref. Otherwise, it will raise the CORBA.BAD_PARAM exception.
Actions taken:
June 13, 2000: received issue
January 12, 2010: closed issue

Issue 3702: tagged types mapped from abstract interfaces (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
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: 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
Revised Text:
Actions taken:
June 13, 2000: received issue
January 12, 2010: closed issue

Issue 3703: mapping of IDL factories (initializers) for valuetypes (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
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.

Resolution: Accept as suggested
Revised Text: Change the first two sentences of Section 4.5.5 to read: An initializer definition shall be mapped to an Ada function that returns an instance of the class of the mapped value reference type. (Thus they will NOT be primitive on the value reference type.) In the example in section 1.10.2.1, change the following Ada code line: function createWBT(w : in CORBA.Long) return Value_Ref; to: function createWBT(w : in CORBA.Long) return Value_Ref’class; Make the same change in the package Exampleb.WeightedBinaryTree in section 1.10.2.5. Make the same change in section 4.5.9. Disposition: Resolved
Actions taken:
June 13, 2000: received issue
January 12, 2010: closed issue

Issue 3704: ada language mapping specification -- TYPOS (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
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

Resolution: Accept as suggested. However, searching has revealed other instances of the problem. The following revised text reflects all changes for these name substitutions.
Revised Text: Change “PortableServer.Servant” to “PortableServer.Servant_Base” in the following places: • In section 1.10.2.5, page 1-14, code for ExampleB.WeightedBinaryTree.Helper • In section 4.6.5 (formerly 4.6.4), page 4-16, example code under first bullet of page. • In section 4.6.6 (formerly 4.6.5), page 4-16, helper code (ExampleB.WeightedBinaryTree.Helper. Change “CORBA.Value_Forward” to “CORBA.Value.Forward” in the following places: • In section 4.9.1, page 4-22, text describing forward definition packages. • In section 5.6.2, page 5-25: in title and in text. Disposition: Resolved
Actions taken:
June 13, 2000: received issue
January 12, 2010: closed issue

Issue 3705: Addition of a constructor for "empty" Any objects. (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
 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;
};

Resolution: 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
Revised Text:
Actions taken:
June 13, 2000: received issue
January 12, 2010: closed issue

Issue 3706: Mapping of CORBA.Request in Ada (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
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);
};

Resolution: 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
Revised Text:
Actions taken:
June 13, 2000: received issue
January 12, 2010: closed issue

Issue 3722: declaration of an UnknownUserException (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
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; };

Resolution: Accept as suggested
Revised Text: Add the following to the exception definitions in the CORBA package in Section 5.4, page 5-12: 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); Add the following text as the seventh and eighth sentences of the text of Section 5.5.3: The UnknownUserException may be raised as the result of Invoke or Get_Response subpograms. In this case the information about the exception can be extracted from an instance of UnknownUserException_Member that can be obtained from the exception by a call to Get_Members.
Actions taken:
June 20, 2000: received issue
January 12, 2010: closed issue

Issue 3736: Inconsistency in the definition of the location of TC_Object (ada-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:
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.

Resolution: Accept as suggested. Add new section describing the CORBA.Object.Helper package
Revised Text: Change the final sentence of section 4.5.7 to read: “See Section5.2.2, “Object,”on page5-3 and Section 5.2.3 “CORBA.Object.Helper” on page 5-5 for more information. ” Add the following as new section 5.2.3: 5.2.3 CORBA.Object.Helper CORBA.Object.Helper provides support for conversion of the base CORBA.Object.Ref type to and from type Any, and the corresponding TypeCode type. package CORBA.Object.Helper is -- base support for type Any TC_Object : constant CORBA.TypeCode.Object; function To_Any (From : in Ref) return CORBA.Any; function From_Any (From : in CORBA.Any) return Ref; -- base support for Widening function To_Ref(From : in Ref'CLASS) return Ref; private -- implementation defined end CORBA.Object.Helper; Disposition: Resolved
Actions taken:
July 4, 2000: received issue
January 12, 2010: closed issue

Issue 5682: Insecurity about literals of typedefed enums (ada-rtf)

Click
here for this issue's archive.
Source: Airbus Group (Mr. Oliver M. Kellogg, oliver.kellogg(at)cassidian.com)
Nature: Uncategorized Issue
Severity:
Summary:
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;

Resolution: Accept the proposed resolution
Revised Text: Add the following as section 2.3.2: 2.3.2 Mapping of Enumeration Literals of Derived Types The Ada language makes the enumeration literals of an enumeration type visible at the point of derivation from a derived type; IDL does not. Because of this, enumeration literals that appear in constant expressions must be qualified by the package name in which the type is defined or derived, rather than the package mapped from the qualified name in IDL. For example, the following IDL definitions: module m_a { enum enum_a { value_1, value_2 }; }; module m_b { typedef m_a::enum_a enum_b; }; const m_b::enum_b bconst = m_a::value_2; must be mapped to bconst : constant m_b.enum_b := m_b.value_2; Disposition: Resolved Ada RTF 1.3 Disposition: Resolved OMG Issue No: 5682 Document
Actions taken:
October 9, 2002: received issue
January 12, 2010: closed issue

Issue 5768: Concern about the mapping of valuetypes to Ada (ada-rtf)

Click
here for this issue's archive.
Source: Airbus Group (Mr. Oliver M. Kellogg, oliver.kellogg(at)cassidian.com)
Nature: Uncategorized Issue
Severity:
Summary:
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.

Resolution: 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
Revised Text:
Actions taken:
November 27, 2002: received issue
January 12, 2010: closed issue; Closed; No Change

Issue 5773: IDL to Ada mapping for valuetypes (ada-rtf)

Click
here for this issue's archive.
Source: Airbus Group (Mr. Oliver M. Kellogg, oliver.kellogg(at)cassidian.com)
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
January 12, 2010: closed issue; Closed; No Change

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


Issue 5859: Mapping of reopened modules to Ada (ada-rtf)

Click
here for this issue's archive.
Source: Airbus Group (Mr. Oliver M. Kellogg, oliver.kellogg(at)cassidian.com)
Nature: Uncategorized Issue
Severity:
Summary:
The IDL to Ada mapping specification version 1.2 (01-10-42)
does not mention how to map reopened IDL modules to Ada.

Resolution: 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.
Revised Text: Add the following to the third paragraph of section 4.3: Any declarations within “re-opened modules”, i.e., “Subsequent occurrences of a module declaration with the same identifier within the same scope”, shall be added to the package that maps the module that was re-opened. Disposition: Resolved
Actions taken:
February 21, 2003: received issue
January 12, 2010: closed issue

Issue 6344: Ada Mapping of Sequences Too Heavy (ada-rtf)

Click
here for this issue's archive.
Source: Objective Interface Systems (Mr. Victor Giddings, victor.giddings(at)mail.ois.com)
Nature: Uncategorized Issue
Severity:
Summary:
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.


Resolution:
Revised Text:
Actions taken:
October 21, 2003: received issue

Discussion:
Deferred due to lack of time.
Disposition: Deferred


Issue 12426: Table 2-1 in section 2.2.4 (ada-rtf)

Click
here for this issue's archive.
Source: Objective Interface Systems (Mr. Victor Giddings, victor.giddings(at)mail.ois.com)
Nature: Enhancement
Severity: Minor
Summary:
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.)

Resolution: Resolved as suggested: change the numeral “4” to “check mark”.
Revised Text: In Table 2-1 in Section 2.2.4 gCharacter Literalsh, in the two gApplicable toh columns, change all occurrences of g4h to the check mark symbol (g.h). Disposition:
Actions taken:
April 30, 2008: received issue
January 12, 2010: closed issue

Issue 12752: Interface/valuetype forward declarations and Ada2005 (ada-rtf)

Click
here for this issue's archive.
Source: Airbus Group (Mr. Oliver M. Kellogg, oliver.kellogg(at)cassidian.com)
Nature: Enhancement
Severity: Medium
Summary:
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;

Resolution: 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.
Revised Text:
Actions taken:
January 12, 2010: closed issue; Closed; No Change

Discussion: