ADA Language Mapping Avatar
  1. OMG Specification

ADA Language Mapping — All Issues

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

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

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

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