ADA 1.3 RTF Avatar
  1. OMG Issue

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