🚀 go-pugleaf

In article <1992Aug11.190816.8623@inmet.camb.inmet.com>, stt@spock.camb.inmet.com (Tucker Taft) writes:
|> 
|> We considered supporting enumeration type extension in Ada 9X, but
|> ultimately dropped it.  One issue (among others) was that values from distinct
|> enumeration extensions of a parent enumeration type
|> might have the same associated integer "code,"
|> making direct comparison between them less meaningful.  That is, equality
|> could be defined, but less-than/greater-than became relatively meaningfless.

Good point; however, C++ already allows duplicate codes, and it is not clear 
why you would want (or would even be allowed to perform) comparisons between
DISTINCT enumeration extensions. I supose you could do it by defining a friend
function of both classes, in which case the meaning of such operations is up
to the implementor of the classes.


|> 
|> One reason we lost interest was the observation that record 
|> extension/derivation tends to make enumeration types less necessary.  
|> Rather than having a variant record/union type with a value of an enumeration
|> type distinguishing the variants, one would simply define distinct
|> derivations.  A virtual function could return a string name
|> for each distinct derivation, corresponding to the enumeration literal.
|> A separate virtual function could return an integer code, if needed.
|> 

That is run time type information via string compares, or via integer compares.
The problem with this is that now the programmer has to be concerned with the
exact values returned from each different class to prevent conflicts within
inheritance trees (and across such trees), whereas with enumeration extension
this could be done by the compilier automatically.

				Eric