Contents Index Search Previous Next
3.9.2 Dispatching Operations of Tagged Types
1
{dispatching operation
[distributed]} {dispatching
call (on a dispatching operation)} {nondispatching
call (on a dispatching operation)} {statically
determined tag} {dynamically
determined tag} {polymorphism}
{run-time polymorphism}
{controlling tag (for a call on
a dispatching operation)} The primitive
subprograms of a tagged type are called
dispatching operations.
[A dispatching operation can be called using a statically determined
controlling tag, in which case the body to be executed is determined
at compile time. Alternatively, the controlling tag can be dynamically
determined, in which case the call
dispatches to a body that is
determined at run time;] such a call is termed a
dispatching call.
[As explained below, the properties of the operands and the context of
a particular call on a dispatching operation determine how the controlling
tag is determined, and hence whether or not the call is a dispatching
call. Run-time polymorphism is achieved when a dispatching operation
is called by a dispatching call.]
{object-oriented
programming (OOP): See dispatching operations of tagged types}
{OOP (object-oriented programming):
See dispatching operations of tagged types} {message:
See dispatching call} {method:
See dispatching subprogram} {virtual
function: See dispatching subprogram}
Language Design Principles
1.a
The controlling tag determination
rules are analogous to the overload resolution rules, except they deal
with run-time type identification (tags) rather than compile-time type
resolution. As with overload resolution, controlling tag determination
may depend on operands or result context.
Static Semantics
2
{call on a dispatching operation}
{dispatching operation}
A
call on a dispatching operation is a call
whose
name or
prefix
denotes the declaration of a primitive subprogram of a tagged type, that
is, a dispatching operation.
{controlling operand}
A
controlling operand in a call on a dispatching
operation of a tagged type
T is one whose corresponding formal
parameter is of type
T or is of an anonymous access type with
designated type
T;
{controlling formal parameter}
the corresponding formal parameter is called a
controlling
formal parameter. If the controlling formal parameter is an access
parameter, the controlling operand is the object designated by the actual
parameter, rather than the actual parameter itself.
{controlling
result} If the call is to a (primitive)
function with result type
T, then the call has a
controlling
result -- the context of the call can control the dispatching.
2.a
Ramification: This definition
implies that a call through the dereference of an access-to-subprogram
value is never considered a call on a dispatching operation. Note also
that if the prefix denotes a renaming_declaration,
the place where the renaming occurs determines whether it is primitive;
the thing being renamed is irrelevant.
3
A name
or expression of a tagged type is either statically tagged, dynamically
tagged, or tag indeterminate, according to whether, when used
as a controlling operand, the tag that controls dispatching is determined
statically by the operand's (specific) type, dynamically by its tag at
run time, or from context. A qualified_expression
or parenthesized expression is statically, dynamically, or indeterminately
tagged according to its operand. For other kinds of names
and expressions, this is determined as follows:
4
- {statically tagged}
The name or
expression is statically tagged if it is of a specific tagged
type and, if it is a call with a controlling result, it has at least
one statically tagged controlling operand;
4.a
Discussion: It is illegal
to have both statically tagged and dynamically tagged controlling operands
in the same call -- see below.
5
- {dynamically tagged}
The name or
expression is dynamically tagged if it is of a class-wide type,
or it is a call with a controlling result and at least one dynamically
tagged controlling operand;
6
- {tag indeterminate}
The name or
expression is tag indeterminate if it is a call with a controlling
result, all of whose controlling operands (if any) are tag indeterminate.
7/1
{
8652/0010}
[A
type_conversion is statically
or dynamically tagged according to whether the type determined by the
subtype_mark is specific or class-wide,
respectively.]
For an object that is designated by an expression whose
expected type is an anonymous access-to-specific tagged type, the object
is dynamically tagged if the expression, ignoring enclosing parentheses,
is of the form X'Access, where X is of a class-wide type, or is of the
form new T'(...), where T denotes a class-wide subtype. Otherwise,
the object For a controlling operand that is designated by an
actual parameter, the controlling operand is statically or dynamically
tagged according to whether the designated type
of the type of the
expression of the actual parameter is specific or class-wide,
respectively.
7.a
Ramification: A type_conversion
is never tag indeterminate, even if its operand is. A designated object
is never tag indeterminate.
7.a.1/1
{8652/0010}
Allocators and access attributes of specific types can be used as
the controlling parameters of dispatching calls.
Legality Rules
8
A call on a dispatching operation shall not have
both dynamically tagged and statically tagged controlling operands.
8.a
Reason: This restriction
is intended to minimize confusion between whether the dynamically tagged
operands are implicitly converted to, or tag checked against the specific
type of the statically tagged operand(s).
9/1
{
8652/0010}
If the expected type for an expression or
name
is some specific tagged type, then the expression or
name
shall not be dynamically tagged unless it is a controlling operand in
a call on a dispatching operation. Similarly, if the expected type for
an expression is an anonymous access-to-specific tagged type, then the
object designated by the expression shall not be dynamically tagged
unless it is expression shall not be of an access-to-class-wide
type unless it designates a controlling operand in a call on a dispatching
operation.
9.a
Reason: This prevents
implicit "truncation" of a dynamically-tagged value to the
specific type of the target object/formal. An explicit conversion is
required to request this truncation.
9.b
Ramification: This rule
applies to all expressions or names
with a specific expected type, not just those that are actual parameters
to a dispatching call. This rule does not apply to a membership test
whose expression is class-wide,
since any type that covers the tested type is explicitly allowed. See
4.5.2.
10/1
{
8652/0011}
In the declaration of a dispatching operation of a tagged type, everywhere
a subtype of the tagged type appears as a subtype of the profile (see
6.1), it shall statically match the first subtype
of the tagged type.
{statically matching (required)
[partial]} If the dispatching operation overrides
an inherited subprogram, it shall be subtype conformant with the inherited
subprogram.
{subtype conformance (required)}
The convention of an inherited or overriding dispatching
operation is the convention of the corresponding primitive operation
of the parent type. An explicitly declared A dispatching operation
shall not be of convention Intrinsic.
If a dispatching operation overrides
the predefined equals operator, then it shall be of convention Ada [(either
explicitly or by default -- see 6.3.1)].
10.a
Reason: These rules ensure
that constraint checks can be performed by the caller in a dispatching
call, and parameter passing conventions match up properly. A special
rule on aggregates prevents values of a tagged type from being created
that are outside of its first subtype.
11
The default_expression
for a controlling formal parameter of a dispatching operation shall be
tag indeterminate. A controlling formal parameter that is an access parameter
shall not have a default_expression.
11.a
Reason: The first part
ensures that the default_expression
always produces the "correct" tag when called with or without
dispatching, or when inherited by a descendant. If it were statically
tagged, the default would be useless for a dispatching call; if it were
dynamically tagged, the default would be useless for a nondispatching
call.
11.b
The second part is consistent
with the first part, since designated objects are never tag-indeterminate.
12
A given subprogram shall not be a dispatching
operation of two or more distinct tagged types.
12.a
Reason: This restriction
minimizes confusion since multiple dispatching is not provided. The normal
solution is to replace all but one of the tagged types with their class-wide
types.
12.a.1/1
Ramification: {8652/0098}
This restriction applies even if the partial view (see 7.3)
of one or both of the types is untagged. This follows from the definition
of dispatching operation: the operation is a dispatching operation anywhere
the full views of the (tagged) types are visible.
13
The explicit declaration of a primitive subprogram
of a tagged type shall occur before the type is frozen (see
13.14).
[For example, new dispatching operations cannot be added after objects
or values of the type exist, nor after deriving a record extension from
it, nor after a body.]
13.a
Reason: This rule is
needed because (1) we don't want people dispatching to things that haven't
been declared yet, and (2) we want to allow tagged type descriptors to
be static (allocated statically, and initialized to link-time-known symbols).
Suppose T2 inherits primitive P from T1, and then overrides P. Suppose
P is called before the declaration of the overriding P. What should
it dispatch to? If the answer is the new P, we've violated the first
principle above. If the answer is the old P, we've violated the second
principle. (A call to the new one necessarily raises Program_Error, but
that's beside the point.)
13.b
Note that a call upon a dispatching
operation of type T will freeze T.
13.c
We considered applying this
rule to all derived types, for uniformity. However, that would be upward
incompatible, so we rejected the idea. As in Ada 83, for an untagged
type, the above call upon P will call the old P (which is arguably confusing).
13.d
Implementation Note: Because
of this rule, the type descriptor can be created (presumably containing
linker symbols pointing at the not-yet-compiled bodies) at the first
freezing point of the type. It also prevents, for a tagged type declared
in a package_specification, overriding
in the body or by a child subprogram.
13.e
Ramification: A consequence
is that for a derived_type_declaration
in a declarative_part, only the
first primitive subprogram can be declared by a subprogram_body.
Dynamic Semantics
14
{execution
(call on a dispatching operation) [partial]} {controlling
tag value} For the execution of a call
on a dispatching operation of a type
T, the
controlling tag
value determines which subprogram body is executed. The controlling
tag value is defined as follows:
15
- {statically determined
tag [partial]} If one or more controlling
operands are statically tagged, then the controlling tag value is statically
determined to be the tag of T.
16
- If one or more controlling operands
are dynamically tagged, then the controlling tag value is not statically
determined, but is rather determined by the tags of the controlling operands.
{Tag_Check [partial]} {check,
language-defined (Tag_Check)} If there
is more than one dynamically tagged controlling operand, a check is made
that they all have the same tag. {Constraint_Error
(raised by failure of run-time check)} If
this check fails, Constraint_Error is raised unless the call is a function_call
whose name denotes the declaration
of an equality operator (predefined or user defined) that returns Boolean,
in which case the result of the call is defined to indicate inequality,
and no subprogram_body is executed.
This check is performed prior to evaluating any tag-indeterminate controlling
operands.
16.a
Reason: Tag mismatch
is considered an error (except for "=" and "/=")
since the corresponding primitive subprograms in each specific type expect
all controlling operands to be of the same type. For tag mismatch with
an equality operator, rather than raising an exception, "="
returns False and "/=" returns True. No equality operator is
actually invoked, since there is no common tag value to control the dispatch.
Equality is a special case to be consistent with the existing Ada 83
principle that equality comparisons, even between objects with different
constraints, never raise Constraint_Error.
17
- If all
of the controlling operands are tag-indeterminate, then:
18
- If the call has a controlling
result and is itself a (possibly parenthesized or qualified) controlling
operand of an enclosing call on a dispatching operation of type T,
then its controlling tag value is determined by the controlling tag value
of this enclosing call;
19
- {statically
determined tag [partial]} Otherwise, the
controlling tag value is statically determined to be the tag of type
T.
19.a
Ramification: This includes
the cases of a tag-indeterminate procedure call, and a tag-indeterminate
function_call that is used to initialize
a class-wide formal parameter or class-wide object.
20
For the execution of a call on a dispatching
operation, the body executed is the one for the corresponding primitive
subprogram of the specific type identified by the controlling tag value.
The body for an explicitly declared dispatching operation is the corresponding
explicit body for the subprogram. The body for an implicitly declared
dispatching operation that is overridden is the body for the overriding
subprogram, [even if the overriding occurs in a private part.] The body
for an inherited dispatching operation that is not overridden is the
body of the corresponding subprogram of the parent or ancestor type.
20.a
To be honest: In the
unusual case in which a dispatching subprogram is explicitly declared
(overridden) by a body (with no preceding subprogram_declaration),
the body for that dispatching subprogram is that body; that is, the ``corresponding
explicit body'' in the above rule is the body itself.
20.b
Reason:
The wording of the above rule is intended to ensure that the same
body is executed for a given tag, whether that tag is determined statically
or dynamically. For a type declared in a package, it doesn't matter whether
a given subprogram is overridden in the visible part or the private part,
and it doesn't matter whether the call is inside or outside the package.
For example:
20.c
package P1 is
type T1 is tagged null record;
procedure Op_A(Arg : in T1);
procedure Op_B(Arg : in T1);
end P1;
20.d
with P1; use P1;
package P2 is
type T2 is new T1 with null record;
procedure Op_A(Param : in T2);
private
procedure Op_B(Param : in T2);
end P2;
20.e/1
with P1; with P2;
procedure Main is
X : P2. T2;
Y : P1. T1'Class := X;
begin
P2.Op_A(Param => X); -- Nondispatching call to a dispatching operation .
P1.Op_A(Arg => Y); -- Dispatching call.
P2.Op_B(Arg => X); -- Nondispatching call to a dispatching operation .
P1.Op_B(Arg => Y); -- Dispatching call.
end Main;
20.f
The two calls to Op_A both execute
the body of Op_A that has to occur in the body of package P2. Similarly,
the two calls to Op_B both execute the body of Op_B that has to occur
in the body of package P2, even though Op_B is overridden in the private
part of P2. Note, however, that the formal parameter names are different
for P2.Op_A versus P2.Op_B. The overriding declaration for P2.Op_B is
not visible in Main, so the name in the call actually denotes the implicit
declaration of Op_B inherited from T1.
20.g
If a call occurs in the program
text before an overriding, which can happen only if the call is part
of a default expression, the overriding will still take effect for that
call.
20.h
Implementation Note: Even
when a tag is not statically determined, a compiler might still
be able to figure it out and thereby avoid the overhead of run-time dispatching.
21
70 The body to be executed
for a call on a dispatching operation is determined by the tag; it does
not matter whether that tag is determined statically or dynamically,
and it does not matter whether the subprogram's declaration is visible
at the place of the call.
22
71 This subclause covers
calls on primitive subprograms of a tagged type. Rules for tagged type
membership tests are described in 4.5.2.
Controlling tag determination for an assignment_statement
is described in 5.2.
23
72 A dispatching call can
dispatch to a body whose declaration is not visible at the place of the
call.
24
73 A call through an access-to-subprogram
value is never a dispatching call, even if the access value designates
a dispatching operation. Similarly a call whose prefix
denotes a subprogram_renaming_declaration
cannot be a dispatching call unless the renaming itself is the declaration
of a primitive subprogram.
Extensions to Ada 83
24.a
{extensions to Ada 83}
The concept of dispatching operations is new.
Contents Index Search Previous Next Legal