Re: Extensible Enummerated types FW: When will next Ada revision be? (83, 95, ?)

["Jeff Creem" <jeff@thecreems.com>]

"Robert Dewar" <robert_dewar@my-deja.com> wrote in message
news:94c61v$h4a$1@nnrp1.deja.com...
> In article <mailman.979975693.13263.comp.lang.ada@ada.eu.org>,
>   comp.lang.ada@ada.eu.org wrote:
> > From: Bob Leif
> > To: Tucker Taft et al.
>
> > I believe that at one time you mentioned the possibility of
> > extending an enumerated type. This would greatly facilitate
> > object oriented programming.
>
> We did indeed consider this possibility, and I even think it
> was in one of the earlier mapping documents, but it was
> excluded because the implementation and description
> difficulties outweighed the usefullness, and further more
> for the specific examples presented, there seemed to be
> perfectly acceptable alternative methods of doing things.
>
> There is quite a bit of semantic structure in Ada that depends
> on knowing the possible set of enumeration types statically.


Of course I would find it useful (at times) to be able to extend the
set of an enumeration type (in a new derived type) even without having some
sort of a class based pointer to an arbitrary version of one of the new
types.

There are of course other perfectly acceptable methods but at times it would
be cleaner to be able to do things
like

type Fruit_Type is (Apple, Orange);
type New_Fruit_Type is new Fruit_Type with (Pear, Kiwi);

A : Fruit_Type := Apple;
B : New_Fruit_Type := New_Fruit_Type(A);


In the past when I have ran into situations like this (where for very
specific reasons I could not add anything
to Fruit_Type) I have resorted to enumeration indexed arrays of enumeration
type look-up tables for the
conversion...Not bad but not as clean as the above.



Whether the extra complexity this imposes on compiler writes (or language
learners) is worth the occasional
convenience is certainly debatable.