| | | |
TOC -- / --.-- / --.--.-- | Index | Search | Syntax | Help

3.9.3 Abstract Types and Subprograms

(1)

An abstract type is a tagged type intended for use as a parent type for type extensions, but which is not allowed to have objects of its own. An abstract subprogram is a subprogram that has no body, but is intended to be overridden at some point when inherited. Because objects of an abstract type cannot be created, a dispatching call to an abstract subprogram always dispatches to some overriding body.

Legality Rules

(2)

An abstract type is a specific type that has the reserved word abstract in its declaration. Only a tagged type is allowed to be declared abstract.

(3)

A subprogram declared by an abstract_subprogram_declaration (see 6.1) is an abstract subprogram. If it is a primitive subprogram of a tagged type, then the tagged type shall be abstract.

(4)

For a derived type, if the parent or ancestor type has an abstract primitive subprogram, or a primitive function with a controlling result, then:

(5)

• If the derived type is abstract or untagged, the inherited subprogram is abstract.

(6)

• Otherwise, the subprogram shall be overridden with a nonabstract subprogram; for a type declared in the visible part of a package, the overriding may be either in the visible or the private part. However, if the type is a generic formal type, the subprogram need not be overridden for the formal type itself; a nonabstract version will necessarily be provided by the actual type.

(7)

A call on an abstract subprogram shall be a dispatching call; nondispatching calls to an abstract subprogram are not allowed.

(8)

The type of an aggregate, or of an object created by an object_declaration or an allocator, or a generic formal object of mode in, shall not be abstract. The type of the target of an assignment operation (see 5.2) shall not be abstract. The type of a component shall not be abstract. If the result type of a function is abstract, then the function shall be abstract.

(9)

If a partial view is not abstract, the corresponding full view shall not be abstract. If a generic formal type is abstract, then for each primitive subprogram of the formal that is not abstract, the corresponding primitive subprogram of the actual shall not be abstract.

(10)

For an abstract type declared in a visible part, an abstract primitive subprogram shall not be declared in the private part, unless it is overriding an abstract subprogram implicitly declared in the visible part. For a tagged type declared in a visible part, a primitive function with a controlling result shall not be declared in the private part, unless it is overriding a function implicitly declared in the visible part.

(11)

A generic actual subprogram shall not be an abstract subprogram. The prefix of an attribute_reference for the Access, Unchecked_Access, or Address attributes shall not denote an abstract subprogram.

NOTES

(12)

(74) Abstractness is not inherited; to declare an abstract type, the reserved word abstract has to be used in the declaration of the type extension.

(13)

(75) A class-wide type is never abstract. Even if a class is rooted at an abstract type, the class-wide type for the class is not abstract, and an object of the class-wide type can be created; the tag of such an object will identify some nonabstract type in the class.

Examples

(14)

Example of an abstract type representing a set of natural numbers:

(15)
       package Sets is
           subtype Element_Type is Natural;
           type Set is abstract tagged null record;
           function Empty return Set is abstract;
           function Union(Left, Right : Set) return Set is abstract;
           function Intersection(Left, Right : Set) return Set is abstract;
           function Unit_Set(Element : Element_Type) return Set is abstract;
           procedure Take(Element : out Element_Type; From : in out Set) is abstract;
       end Sets;

NOTES

(16)

(76) Notes on the example: Given the above abstract type, one could then derive various (nonabstract) extensions of the type, representing alternative implementations of a set. One might use a bit vector, but impose an upper bound on the largest element representable, while another might use a hash table, trading off space for flexibility.

| | | |
TOC -- / --.-- / --.--.-- | Index | Search | Syntax | Help

-- Email comments, additions, corrections, gripes, kudos, etc. to: