Version 1.1 of ais/ai-00261.txt

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

!standard 13.13.2 (31)          01-02-13 AI95-00261/00
!standard 13.13.2 (34)
!class amendment 01-02-13
!status received 01-02-13
!priority Low
!difficulty Medium
!subject Extending enumeration types
!summary
!problem
The addition of child libraries facilitates programing by extension. The child, which evolves from the parent, can be either a supplement to or specialization of the parent. In any case the specification of the child should be limited to types and methods specific to the child.
In the case of enumerated types, this approach is violated. Theoretically, the author of the software has to know in advance all of the values of the enumerated type. The child libraries would then specialize this type by employing subtypes.
Another argument goes back to minimizing coupling and maximizing cohesion. For instance, the universe of name prefixes could easily exceed 100. For instance, in the case of Great Britain, all of the titles of nobility have to be added. The military and public officials would also have to be included. A simple example for this is a registration form for SIGAda. Since one of the best rules for data entry, is to minimize user entry of strings, pull-down menus with a list of choices are a good solution for the entry of enumerated types. However, the use of a menu with a list of 100 or more selections is highly user-hostile. Therefore a subtype will have to be used to populate the menu. Since it is extremely doubtful that a significant number of clergy or members of the nobility attend SIGAda, the number of items in the Name.Prefix menu can be reduced by neither including the prefixes for the clergy nor the nobility. It would be simpler to have the values for the clergy and nobility in separate child packages that can if need be withed. The parent package will have to be modified each time a prefix necessary for the child package has been discovered to have been omitted. It should be noted, that it is quite easy to omit, one or two items in an enumerated type. The flexibility of being able to add elements to an enumerated type will result in a smaller number of items being included in the original enumeration and simplify the creation of child packages.
!proposal
Provide a mechanism to extend enumeration types.
Possible Approaches: type Prefix_Type is (None, Mr, Ms, Miss, Mrs, Dr, Prof, Rev, Other);
(1) supertype Army_Prefix_Type is (Prefix_Type, Private, Corporal, Sergeant, Lieutenant, Captain, Major, Colonel, General);
(2) type Army_Prefix_Type is new Prefix_Type with (Private, Corporal, Sergeant, Lieutenant, Captain, Major, Colonel, General);
(3) type Army_Prefix_Type is (Prefix_Type'range & ((Private, Corporal, Sergeant, Lieutenant, Captain, Major, Colonel, General));
Example (1) is expressive; however it requires a new keyword supertype, which is an antonym of subtype and thus provides symmetry. Example (2) uses the "is new" construct, which is severely overloaded. Example (3) uses the "&" operator and is analogous to string handling.
!discussion
!example
!ACATS test
!appendix

From: Robert C. Leif, Ph.D.
Sent: Sunday, February 11, 2001 11:13 AM
Topic: Extensible Enumerated Types
Reference: RM95-3.5.1 (pp. 37)
Keywords: Extensible, Enumerated, Types, Supertypes

1. Discussion:
	1.1 Introduction:
The addition of child libraries facilitates programing by extension. The
child, which evolves from the parent, can be either a supplement to or
specialization of the parent. In any case the specification of the child
should be limited to types and methods specific to the child.

In the case of enumerated types, this approach is violated. Theoretically,
the author of the software has to know in advance all of the values of the
enumerated type. The child libraries would then specialize this type by
employing subtypes.

Another argument goes back to minimizing coupling and maximizing cohesion.
For instance, the universe of name prefixes could easily exceed 100. For
instance, in the case of Great Britain, all of the titles of nobility have
to be added. The military and public officials would also have to be
included. A simple example for this is a registration form for SIGAda. Since
one of the best rules for data entry, is to minimize user entry of strings,
pull-down menus with a list of choices are a good solution for the entry of
enumerated types. However, the use of a menu with a list of 100 or more
selections is highly user-hostile. Therefore a subtype will have to be used
to populate the menu. Since it is extremely doubtful that a significant
number of clergy or members of the nobility attend SIGAda, the number of
items in the Name.Prefix menu can be reduced by neither including the
prefixes for the clergy nor the nobility. It would be simpler to have the
values for the clergy and nobility in separate child packages that can if
need be withed. The parent package will have to be modified each time a
prefix necessary for the child package has been discovered to have been
omitted. It should be noted, that it is quite easy to omit, one or two items
in an enumerated type. The flexibility of being able to add elements to an
enumerated type will result in a smaller number of items being included in
the original enumeration and simplify the creation of child packages.

2. Possible Approaches:
type Prefix_Type is (None, Mr, Ms, Miss, Mrs, Dr, Prof, Rev, Other);

(1)
supertype Army_Prefix_Type is (Prefix_Type, Private, Corporal, Sergeant,
Lieutenant, Captain, Major, Colonel, General);

(2)
type Army_Prefix_Type is new Prefix_Type with (Private, Corporal, Sergeant,
Lieutenant, Captain, Major, Colonel, General);

(3)
type Army_Prefix_Type is (Prefix_Type'range & ((Private, Corporal, Sergeant,
Lieutenant, Captain, Major, Colonel, General));

Example (1) is expressive; however it requires a new keyword supertype,
which is an antonym of subtype and thus provides symmetry.
Example (2) uses the "is new" construct, which is severely overloaded.
Example (3) uses the "&" operator and is analogous to string handling.

****************************************************************

From: Michael Yoder
Sent: Tuesday, February 13, 2001 2:31 PM

I think the case with the most potential difficulty would be

     type E is new Wide_Character with (Fee, Fie, Foe, ...);

which isn't insuperably hard IMO.  I am personally enumerationophilic and
would welcome such an extension, but I suspect the issue has been discussed
previously.  :-)  Speaking as a user, I would rate this feature as nice but
not necessary, though there's been more than one case I can recall where it
would have been welcome.  I am sure I have heard numerous users wish for
it, but can't judge how intense these desires were.

A concomitant extension which would be desirable (especially when extending
Wide_Character) is a way to write a representation clause which specifies
values for only the new literals.  Something like

     for E use Wide_Character'Representation & (Fee => 16#10000#, Fie =>
16#10001#, ...);

Mike Yoder

****************************************************************

Questions? Ask the ACAA Technical Agent