Version 1.1 of ais/ai-00390.txt

Unformatted version of ais/ai-00390.txt version 1.1
Other versions for file ais/ai-00390.txt

!standard 08.05.04 (02)          04-11-13 AI95-00390/01
!standard 08.05.04 (03)
!class amendment 04-11-13
!status work item 04-11-13
!status received 04-11-13
!priority Low
!difficulty Easy
!subject Defining by renaming an inherited subprogram
The notation "<>" in a subprogram_renaming_declaration may be used to define a primitive subprogram in terms of a same-named inherited subprogram.
When defining a private type, it is often the case that one or more of the operations of the full type want to be exposed. Ada provides no easy way to do that without having the programmer explicitly write wrappers. This is a nuisance and a potential source of errors due to cut-and-paste mistakes or other mistakes that occur when programmers are forced to due repetitive menial tasks.
A renaming-as-body may be given in the private part of a package where the renamed subprogram is identified simply with a "<>". What this notation means is that the inherited subprogram of the same name as the subprogram being defined is to be renamed.
Add after 8.5.4(2):
subprogram_renaming_as_body ::= subprogram_renaming_declaration | subprogram_specification renames <>
Add after 8.5.4(3):
In a subprogram_renaming_as_body with "RENAMES <>", the renamed callable entity is the inherited subprogram or predefined operator that is overridden by the subprogram_declaration completed by the renaming.
This AI attempts to fix a long-standing difficulty with private types, where one wants to expose some but not all of the operations of the full type. To do so currently, one must go through a tedious and hence error-prone process of creating wrappers for all operations of the full type to be exposed. The proposed notation seems a natural solution, given the renaming-as-body capability, and it has been proposed several times in the past. A potential justification for doing this now is that we have added a number of containers that provide large numbers of operations, of which only a subset might be appropriate for a private type implemented using one of these container abstractions.
(** Missing **)
!ACATS test
ACATS tests need to be constructed to test this feature.

From: Tucker Taft
Sent: Saturday, November 13, 2004  5:34 PM

Here is an AI [This is version /01 - ED] attempting to address a
long-standing annoyance with private types, where one wants to expose
some but not all of the operations of the full type.
This seems more important now that we have a number of
container abstractions which provide large numbers of
operations, only some of which would typically be
exposed for a private type implemented in terms of
one of these containers.


Questions? Ask the ACAA Technical Agent