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.

No Data Available

Summary: Section 21.10:

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

No Data Available

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

No Data Available

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;

No Data Available

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;

No Data Available

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.

No Data Available

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.

No Data Available

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.

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.