ADA Language Mapping Avatar
  1. OMG Specification

ADA Language Mapping — All Issues

  • Acronym: ADA
  • Issues Count: 55
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
ADA12-31 Mapping of operation parameters of same interface type. ADA 1.1 ADA 1.2 Resolved closed
ADA12-32 ptc/99-02-02 page 21-5 Server Side, common root type CORBA.Object.Objec ADA 1.0 ADA 1.2 Resolved closed
ADA12-27 The name of the mapped type shall be "Fixed_" prepended ADA 1.1 ADA 1.2 Resolved closed
ADA12-30 Name and scope of instantiation of CORBA.Sequences.{Un}Bounded ADA 1.1 ADA 1.2 Resolved closed
ADA12-29 Impl methods should be dispatchable ADA 1.1 ADA 1.2 Resolved closed
ADA12-28 Method for converting an Object to a Ref ADA 1.1 ADA 1.2 Resolved closed
ADA12-26 Section 21.8.9: Examples ADA 1.1 ADA 1.2 Resolved closed
ADA12-25 Error in section 21.3.3 ADA 1.1 ADA 1.2 Resolved closed
ADA12-24 23.8.1 Package CORBA ADA 1.0 ADA 1.2 Resolved closed
ADA12-22 23.5.5 Mapping for Interfaces (Client-Side Specific) ADA 1.0 ADA 1.2 Resolved closed
ADA12-21 Mapping of Operations (23.5.9) "Returns" parameter ADA 1.0 ADA 1.2 Resolved closed
ADA12-23 23.5.5 Mapping for Interfaces (Client-Side Specific) ADA 1.0 ADA 1.2 Resolved closed
ADA12-17 TypeCode in 23.6.6 ADA 1.0 ADA 1.2 Resolved closed
ADA12-16 NamedValue in 23.6.1 ADA 1.0 ADA 1.2 Resolved closed
ADA12-18 list_initial_services and resolve_initial_references are missing ADA 1.0 ADA 1.2 Resolved closed
ADA12-19 23.6.8 Object circularities ADA 1.0 ADA 1.2 Resolved closed
ADA12-20 Parameter Result in Createrequest cannot be "in out NamedValue ADA 1.0 ADA 1.2 Resolved closed
ADA12-8 IDL to Ada Mapping: Ada package CORBA.Object (01) ADA 1.0 ADA 1.2 Resolved closed
ADA12-7 Ada Language Mapping: Section 23.5.5, Mapping for Interface ADA 1.0 ADA 1.2 Resolved closed
ADA12-6 Ada and the POA ADA 1.0 ADA 1.2 Resolved closed
ADA12-5 Ada issue: Type string in package CORBA spec ADA 1.0 ADA 1.2 Resolved closed
ADA12-10 Chapter 23.2.7 of CORBA 2.2, IDL to Ada Mapping ( pragma Subsystem) ADA 1.0 ADA 1.2 Resolved closed
ADA12-9 Mapping of IDL to Ada: Ada package CORBA.Object ADA 1.0 ADA 1.2 Resolved closed
ADA12-12 Mapping of structure, union or exception types ADA 1.0 ADA 1.2 Resolved closed
ADA12-11 Nil object reference (CORBA v. 2.2) ADA 1.0 ADA 1.2 Resolved closed
ADA12-2 Ada mapping deficiency - orbos/97-09-26 (2) ADA 1.0 ADA 1.2 Resolved closed
ADA12-1 Ada mapping deficiency - orbos/97-09-26 ADA 1.0 ADA 1.2 Resolved closed
ADA12-14 Mapping for typedef ADA 1.0 ADA 1.2 Resolved closed
ADA12-13 Mapping of sequesnce types ADA 1.0 ADA 1.2 Resolved closed
ADA12-3 Ada mapping deficiency - orbos/97-09-26 (3) ADA 1.0 ADA 1.2 Resolved closed
ADA12-4 Ada mapping issue ADA 1.0 ADA 1.2 Resolved closed
ADA12-15 Mapping for standard exceptions ADA 1.0 ADA 1.2 Resolved closed
ADA13-21 Interface/valuetype forward declarations and Ada2005 ADA 1.2 ADA 1.3 Closed; No Change closed
ADA-1 The Ada mapping of the Interface Repository. ADA 1.0 open
ADA-2 Ada Mapping of Sequences Too Heavy ADA 1.0 open
ADA13-18 IDL to Ada mapping for valuetypes ADA 1.2 ADA 1.3 Closed; No Change closed
ADA13-19 Mapping of reopened modules to Ada ADA 1.2 ADA 1.3 Resolved closed
ADA13-20 Table 2-1 in section 2.2.4 ADA 1.2 ADA 1.3 Resolved closed
ADA13-9 tagged types mapped from abstract interfaces ADA 1.2 ADA 1.3 Resolved closed
ADA13-8 narrowing of valuetypes ADA 1.2 ADA 1.3 Resolved closed
ADA13-7 Inconsistency in the definition of implementation object types. ADA 1.2 ADA 1.3 Resolved closed
ADA13-17 Concern about the mapping of valuetypes to Ada ADA 1.2 ADA 1.3 Closed; No Change closed
ADA13-16 Insecurity about literals of typedefed enums ADA 1.2 ADA 1.3 Resolved closed
ADA13-2 Mapping for String Types - Bounded Strings ADA 1.2 ADA 1.3 Resolved closed
ADA13-15 Inconsistency in the definition of the location of TC_Object ADA 1.2 ADA 1.3 Resolved closed
ADA13-14 declaration of an UnknownUserException ADA 1.2 ADA 1.3 Resolved closed
ADA13-13 Mapping of CORBA.Request in Ada ADA 1.2 ADA 1.3 Resolved closed
ADA13-12 Addition of a constructor for "empty" Any objects. ADA 1.2 ADA 1.3 Resolved closed
ADA13-11 ada language mapping specification -- TYPOS ADA 1.2 ADA 1.3 Resolved closed
ADA13-10 mapping of IDL factories (initializers) for valuetypes ADA 1.2 ADA 1.3 Resolved closed
ADA13-6 CORBA 2.3 Ada, Mapping for Wide String Types ADA 1.2 ADA 1.3 Resolved closed
ADA13-5 21.2.7 Mapping Summary - Names and Scoping ADA 1.2 ADA 1.3 Resolved closed
ADA13-4 ptc/99-02-02: 21.22.1 Handling Known Types ADA 1.2 ADA 1.3 Resolved closed
ADA13-3 ptc/99-02-02: Impl side mapping and the POA ADA 1.2 ADA 1.3 Resolved closed
ADA13-1 Suggestion on mapping the OMG IDL language to Ada ADA 1.1 ADA 1.3 Resolved closed

Issues Descriptions

Mapping of operation parameters of same interface type.

  • Key: ADA12-31
  • Legacy Issue Number: 2459
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: ADA 1.1 — Fri, 19 Feb 1999 05:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ptc/99-02-02 page 21-5 Server Side, common root type CORBA.Object.Objec

  • Key: ADA12-32
  • Legacy Issue Number: 2632
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: ADA 1.0 — Wed, 5 May 1999 04:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The name of the mapped type shall be "Fixed_" prepended

  • Key: ADA12-27
  • Legacy Issue Number: 2044
  • Status: closed  
  • Source: Anonymous
  • 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, ...

  • Reported: ADA 1.1 — Tue, 6 Oct 1998 04:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Name and scope of instantiation of CORBA.Sequences.{Un}Bounded

  • Key: ADA12-30
  • Legacy Issue Number: 2458
  • Status: closed  
  • Source: Anonymous
  • 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.)

  • Reported: ADA 1.1 — Fri, 19 Feb 1999 05:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Impl methods should be dispatchable

  • Key: ADA12-29
  • Legacy Issue Number: 2262
  • Status: closed  
  • Source: Anonymous
  • 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;

  • Reported: ADA 1.1 — Wed, 16 Dec 1998 05:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Method for converting an Object to a Ref

  • Key: ADA12-28
  • Legacy Issue Number: 2209
  • Status: closed  
  • Source: Anonymous
  • 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;

  • Reported: ADA 1.1 — Fri, 13 Nov 1998 05:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 21.8.9: Examples

  • Key: ADA12-26
  • Legacy Issue Number: 2043
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: ADA 1.1 — Tue, 6 Oct 1998 04:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Error in section 21.3.3

  • Key: ADA12-25
  • Legacy Issue Number: 2036
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: ADA 1.1 — Mon, 5 Oct 1998 04:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

23.8.1 Package CORBA

  • Key: ADA12-24
  • Legacy Issue Number: 1896
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: ADA 1.0 — Fri, 28 Aug 1998 04:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    CORBA.String) return Standard.String; In my opinion, the frequency with which these conversion f

  • Updated: Fri, 6 Mar 2015 20:58 GMT

23.5.5 Mapping for Interfaces (Client-Side Specific)

  • Key: ADA12-22
  • Legacy Issue Number: 1846
  • Status: closed  
  • Source: Anonymous
  • 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 ..." ?

  • Reported: ADA 1.0 — Thu, 20 Aug 1998 04:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Mapping of Operations (23.5.9) "Returns" parameter

  • Key: ADA12-21
  • Legacy Issue Number: 1818
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: ADA 1.0 — Mon, 17 Aug 1998 04:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

23.5.5 Mapping for Interfaces (Client-Side Specific)

  • Key: ADA12-23
  • Legacy Issue Number: 1856
  • Status: closed  
  • Source: Anonymous
  • 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)

  • Reported: ADA 1.0 — Mon, 24 Aug 1998 04:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TypeCode in 23.6.6

  • Key: ADA12-17
  • Legacy Issue Number: 1811
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: ADA 1.0 — Thu, 13 Aug 1998 04:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

NamedValue in 23.6.1

  • Key: ADA12-16
  • Legacy Issue Number: 1810
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: ADA 1.0 — Thu, 13 Aug 1998 04:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

list_initial_services and resolve_initial_references are missing

  • Key: ADA12-18
  • Legacy Issue Number: 1812
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: ADA 1.0 — Thu, 13 Aug 1998 04:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

23.6.8 Object circularities

  • Key: ADA12-19
  • Legacy Issue Number: 1813
  • Status: closed  
  • Source: Anonymous
  • 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.
  • Reported: ADA 1.0 — Thu, 13 Aug 1998 04:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parameter Result in Createrequest cannot be "in out NamedValue

  • Key: ADA12-20
  • Legacy Issue Number: 1814
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: ADA 1.0 — Thu, 13 Aug 1998 04:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL to Ada Mapping: Ada package CORBA.Object (01)

  • Key: ADA12-8
  • Legacy Issue Number: 1387
  • Status: closed  
  • Source: Anonymous
  • 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.)

  • Reported: ADA 1.0 — Tue, 19 May 1998 04:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ada Language Mapping: Section 23.5.5, Mapping for Interface

  • Key: ADA12-7
  • Legacy Issue Number: 1359
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: ADA 1.0 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ada and the POA

  • Key: ADA12-6
  • Legacy Issue Number: 1320
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: ADA 1.0 — Wed, 13 May 1998 04:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ada issue: Type string in package CORBA spec

  • Key: ADA12-5
  • Legacy Issue Number: 1112
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: ADA 1.0 — Thu, 26 Mar 1998 05:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 23.2.7 of CORBA 2.2, IDL to Ada Mapping ( pragma Subsystem)

  • Key: ADA12-10
  • Legacy Issue Number: 1504
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: ADA 1.0 — Thu, 4 Jun 1998 04:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Mapping of IDL to Ada: Ada package CORBA.Object

  • Key: ADA12-9
  • Legacy Issue Number: 1388
  • Status: closed  
  • Source: Anonymous
  • 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:

  • Reported: ADA 1.0 — Tue, 19 May 1998 04:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Mapping of structure, union or exception types

  • Key: ADA12-12
  • Legacy Issue Number: 1806
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: ADA 1.0 — Thu, 13 Aug 1998 04:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Nil object reference (CORBA v. 2.2)

  • Key: ADA12-11
  • Legacy Issue Number: 1702
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: ADA 1.0 — Mon, 20 Jul 1998 04:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ada mapping deficiency - orbos/97-09-26 (2)

  • Key: ADA12-2
  • Legacy Issue Number: 734
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: ADA 1.0 — Fri, 3 Oct 1997 04:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    Accepted.close isse

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ada mapping deficiency - orbos/97-09-26

  • Key: ADA12-1
  • Legacy Issue Number: 733
  • Status: closed  
  • Source: Anonymous
  • 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"

  • Reported: ADA 1.0 — Fri, 3 Oct 1997 04:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    close with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Mapping for typedef

  • Key: ADA12-14
  • Legacy Issue Number: 1808
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: ADA 1.0 — Thu, 13 Aug 1998 04:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Mapping of sequesnce types

  • Key: ADA12-13
  • Legacy Issue Number: 1807
  • Status: closed  
  • Source: Anonymous
  • 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
  • Reported: ADA 1.0 — Thu, 13 Aug 1998 04:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ada mapping deficiency - orbos/97-09-26 (3)

  • Key: ADA12-3
  • Legacy Issue Number: 735
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: ADA 1.0 — Fri, 3 Oct 1997 04:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    Accepted, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ada mapping issue

  • Key: ADA12-4
  • Legacy Issue Number: 996
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: ADA 1.0 — Mon, 9 Mar 1998 05:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    :Object and

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Mapping for standard exceptions

  • Key: ADA12-15
  • Legacy Issue Number: 1809
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: ADA 1.0 — Thu, 13 Aug 1998 04:00 GMT
  • Disposition: Resolved — ADA 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interface/valuetype forward declarations and Ada2005

  • Key: ADA13-21
  • Legacy Issue Number: 12752
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • 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;

  • Reported: ADA 1.2 — Thu, 7 Aug 2008 04:00 GMT
  • Disposition: Closed; No Change — ADA 1.3
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

The Ada mapping of the Interface Repository.

  • Key: ADA-1
  • Legacy Issue Number: 3639
  • Status: open  
  • Source: Anonymous
  • 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.

  • Reported: ADA 1.0 — Tue, 23 May 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Ada Mapping of Sequences Too Heavy

  • Key: ADA-2
  • Legacy Issue Number: 6344
  • Status: open  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • 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.

  • Reported: ADA 1.0 — Tue, 21 Oct 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

IDL to Ada mapping for valuetypes

  • Key: ADA13-18
  • Legacy Issue Number: 5773
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • 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?

  • Reported: ADA 1.2 — Mon, 2 Dec 2002 05:00 GMT
  • Disposition: Closed; No Change — ADA 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Mapping of reopened modules to Ada

  • Key: ADA13-19
  • Legacy Issue Number: 5859
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

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

  • Reported: ADA 1.2 — Fri, 21 Feb 2003 05:00 GMT
  • Disposition: Resolved — ADA 1.3
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Table 2-1 in section 2.2.4

  • Key: ADA13-20
  • Legacy Issue Number: 12426
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • 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.)

  • Reported: ADA 1.2 — Wed, 30 Apr 2008 04:00 GMT
  • Disposition: Resolved — ADA 1.3
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

tagged types mapped from abstract interfaces

  • Key: ADA13-9
  • Legacy Issue Number: 3702
  • Status: closed  
  • Source: Anonymous
  • 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)

  • Reported: ADA 1.2 — Tue, 13 Jun 2000 04:00 GMT
  • Disposition: Resolved — ADA 1.3
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

narrowing of valuetypes

  • Key: ADA13-8
  • Legacy Issue Number: 3701
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: ADA 1.2 — Tue, 13 Jun 2000 04:00 GMT
  • Disposition: Resolved — ADA 1.3
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistency in the definition of implementation object types.

  • Key: ADA13-7
  • Legacy Issue Number: 3627
  • Status: closed  
  • Source: Anonymous
  • 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;"
  • Reported: ADA 1.2 — Fri, 19 May 2000 04:00 GMT
  • Disposition: Resolved — ADA 1.3
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Concern about the mapping of valuetypes to Ada

  • Key: ADA13-17
  • Legacy Issue Number: 5768
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • 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.

  • Reported: ADA 1.2 — Wed, 27 Nov 2002 05:00 GMT
  • Disposition: Closed; No Change — ADA 1.3
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Insecurity about literals of typedefed enums

  • Key: ADA13-16
  • Legacy Issue Number: 5682
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • 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;

  • Reported: ADA 1.2 — Wed, 9 Oct 2002 04:00 GMT
  • Disposition: Resolved — ADA 1.3
  • Disposition Summary:

    Accept the proposed resolution

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Mapping for String Types - Bounded Strings

  • Key: ADA13-2
  • Legacy Issue Number: 2612
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: ADA 1.2 — Mon, 26 Apr 1999 04:00 GMT
  • Disposition: Resolved — ADA 1.3
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistency in the definition of the location of TC_Object

  • Key: ADA13-15
  • Legacy Issue Number: 3736
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: ADA 1.2 — Tue, 4 Jul 2000 04:00 GMT
  • Disposition: Resolved — ADA 1.3
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

declaration of an UnknownUserException

  • Key: ADA13-14
  • Legacy Issue Number: 3722
  • Status: closed  
  • Source: Anonymous
  • 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; }

    ;

  • Reported: ADA 1.2 — Tue, 20 Jun 2000 04:00 GMT
  • Disposition: Resolved — ADA 1.3
  • Disposition Summary:

    Accept as suggested

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Mapping of CORBA.Request in Ada

  • Key: ADA13-13
  • Legacy Issue Number: 3706
  • Status: closed  
  • Source: Anonymous
  • 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); }

    ;

  • Reported: ADA 1.2 — Tue, 13 Jun 2000 04:00 GMT
  • Disposition: Resolved — ADA 1.3
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Addition of a constructor for "empty" Any objects.

  • Key: ADA13-12
  • Legacy Issue Number: 3705
  • Status: closed  
  • Source: Anonymous
  • 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; }

    ;

  • Reported: ADA 1.2 — Tue, 13 Jun 2000 04:00 GMT
  • Disposition: Resolved — ADA 1.3
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

ada language mapping specification -- TYPOS

  • Key: ADA13-11
  • Legacy Issue Number: 3704
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: ADA 1.2 — Tue, 13 Jun 2000 04:00 GMT
  • Disposition: Resolved — ADA 1.3
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

mapping of IDL factories (initializers) for valuetypes

  • Key: ADA13-10
  • Legacy Issue Number: 3703
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: ADA 1.2 — Tue, 13 Jun 2000 04:00 GMT
  • Disposition: Resolved — ADA 1.3
  • Disposition Summary:

    Accept as suggested

  • Updated: Fri, 6 Mar 2015 20:57 GMT

CORBA 2.3 Ada, Mapping for Wide String Types

  • Key: ADA13-6
  • Legacy Issue Number: 2891
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: ADA 1.2 — Wed, 15 Sep 1999 04:00 GMT
  • Disposition: Resolved — ADA 1.3
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

21.2.7 Mapping Summary - Names and Scoping

  • Key: ADA13-5
  • Legacy Issue Number: 2657
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • 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.

  • Reported: ADA 1.2 — Tue, 18 May 1999 04:00 GMT
  • Disposition: Resolved — ADA 1.3
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

ptc/99-02-02: 21.22.1 Handling Known Types

  • Key: ADA13-4
  • Legacy Issue Number: 2656
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: ADA 1.2 — Tue, 18 May 1999 04:00 GMT
  • Disposition: Resolved — ADA 1.3
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

ptc/99-02-02: Impl side mapping and the POA

  • Key: ADA13-3
  • Legacy Issue Number: 2649
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: ADA 1.2 — Mon, 10 May 1999 04:00 GMT
  • Disposition: Resolved — ADA 1.3
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Suggestion on mapping the OMG IDL language to Ada

  • Key: ADA13-1
  • Legacy Issue Number: 2095
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: ADA 1.1 — Mon, 19 Oct 1998 04:00 GMT
  • Disposition: Resolved — ADA 1.3
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:57 GMT