Somebody over in comp.lang.c++ asked an interesting question about the
case where you have two or more enum types declared in the same scope
and where each enum type contains a declaration of a particular enumerator
name, like:

 enum fruit { apple, orange, banana };
 enum color { red, orange, yellow };


You can't do this because you will get an error on the (re)declaration of
`orange'.

Sometimes though, it would be nice to be able to do something like this,
e.g. when you want to have one type which refers to a whole big range
of enumerator values, and yet another type which represents some "subrange"
of the larger range of enumerator values.

So I was thinking... this sounds like a job for ... ta da!  Inheritance!

Sure.  Why not?

 enum light_color { pink, yellow, aqua };

 enum color : light_color { red, green, blue };


 enum light_color LC;
 enum color C;


  LC = pink; // ok
  C = pink; // also ok
  LC = red; // buzzzzzt... wrong... but thanks for playing


Does anybody (other than me) think that this might be a good idea?

After all, in C++ we *do* now have strict type checking for enum types,
however we *don't* have anything like Pascal subranges.

In article <5701@lupine.NCD.COM> rfg@lupine.ncd.com (Ron Guilmette) writes:
>Sometimes though, it would be nice to be able to do something like this,
>e.g. when you want to have one type which refers to a whole big range
>of enumerator values, and yet another type which represents some "subrange"
>of the larger range of enumerator values.

[ deleted ]

>So I was thinking... this sounds like a job for ... ta da!  Inheritance!
>
>Does anybody (other than me) think that this might be a good idea?
>
>After all, in C++ we *do* now have strict type checking for enum types,
>however we *don't* have anything like Pascal subranges.

I have wanted something like this for some time.
It would be nice to have the derived enumerator's first indentifier
automagicly be one more than the last identifier of it's base.

I think that I could have made use of such a thing had it existed.

----------
richard~

Ron Guilmette <rfg@lupine.ncd.com> writes:
|So I was thinking... this sounds like a job for ... ta da!  Inheritance!
|
|Sure.  Why not?
|
| enum light_color { pink, yellow, aqua };
|
| enum color : light_color { red, green, blue };

A problem with this is that inheritance denotes an is-a relationship.
That is, an instance of a derived object is-a base object as well.
This would not be the case with the above since a 'color' can have a
value that has no meaning for a 'light_color'.

Good idea, though.  I could use something like this -- especially for
returned status codes.

     Reid
--
Reid Ellis
rae@utcs.toronto.edu        ||               rae@alias.com
CDA0610@applelink.apple.com ||      +1 416 362 9181 [work]

>>>>> On 25 May 91 07:43:08 GMT, rfg@lupine.ncd.com (Ron Guilmette) said:

Ron>  enum fruit { apple, orange, banana };
Ron>  enum color { red, orange, yellow };

Ron> You can't do this because you will get an error on the (re)declaration of
Ron> `orange'.

Ron> Sometimes though, it would be nice to be able to do something like this,
Ron> e.g. when you want to have one type which refers to a whole big range of
Ron> enumerator values, and yet another type which represents some "subrange"
Ron> of the larger range of enumerator values.

Ron> So I was thinking... this sounds like a job for ... ta da!  Inheritance!

Ron>  enum light_color { pink, yellow, aqua };
Ron>  enum color : light_color { red, green, blue };

This is a bit confusing as you would tend to think of Light_Color as a
derivative of Color, not vice versa.  It would probably also be true that
people would start with a general definition (Color) and later specialize it
to their needs (Light_Color).  Perhaps something like:

enum color { pink, yellow, aqua, red, green, blue };
enum light_color : color { pink, yellow, aqua };

BTW, how hard would this be to simulate using classes?
--
====================================================================
David Masterson     Consilium, Inc.
(415) 691-6311     640 Clyde Ct.
uunet!cimshop!davidm    Mtn. View, CA  94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"

In article <CIMSHOP!DAVIDM.91May26223941@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes:

>>>>> On 25 May 91 07:43:08 GMT, rfg@lupine.ncd.com (Ron Guilmette) said:

Ron> this sounds like a job for ... ta da!  Inheritance!

Ron>  enum light_color { pink, yellow, aqua };
Ron>  enum color : light_color { red, green, blue };

David> This is a bit confusing as you would tend to think of Light_Color as a
David> derivative of Color, not vice versa.

Your not alone in this thought.  Cardelli and Wegner define inclusion
polymorphism (or inheritance if you prefer) for variant types (enums
in C++) in this way.  For anyone that is interested in these sorts of
issues, I recommend reading :-

On Understanding Types, Data Abstraction and Polymorphism
L. Cardelli and P. Wegner
Computing Surveys 17(4):480-521 December 1985

and :-

Type Theories and Object-Oriented Programming
Scott Danfor and Chris Tomlinson
Computing Surveys 20(1):29-72 March 1988

Stephen J. Bevan   bevan@cs.man.ac.uk

In article <1991May26.082057.6735@alias.com> rae@alias.com (Reid Ellis) writes:
>Ron Guilmette <rfg@lupine.ncd.com> writes:
>|So I was thinking... this sounds like a job for ... ta da!  Inheritance!
>| enum light_color { pink, yellow, aqua };
>| enum color : light_color { red, green, blue };
>
>A problem with this is that inheritance denotes an is-a relationship.
>That is, an instance of a derived object is-a base object as well.
>This would not be the case with the above since a 'color' can have a
>value that has no meaning for a 'light_color'.

Wrong.   C++ and computer programming don't have 'is_a' relationships.
They exist in the minds of the programmers.
You are anthromorphizing the programming language by thinking of things
this way.

For instance 'is_a' does not apply at all if you have a private base class.
The derived object cannot be used where a base object is asked for.
You are also allowed to think of inheritance as reading 'and_more'
(which would be appropriate to enumerations).
For example, I can imagine the following situation.

A computer is running some experiment, and we have a class which stores
all the information that will control the experiment:

class experimental_conditions {
 ...
 double voltage, other_experimental_parameters;
 ...
 };

Then, we can make a class which stores the measured data along
with the conditions:

class datum : public experimental_conditions {
 ...
 double whatever_was_measured;
 ...
 };

Now, whatever_was_measured is meaningless unless it is attached to
the conditions that gave rise to it.  For instance, 42 may be the
answer, but it would be even more meaningful if the question were attached.
So, now you can pass a datum to various routines which might display
the conditions on menus, or whatever.

I suppose you can think that 'a datum is an experimental condition',
but you'd really have to stretch the English language and the meaning
of the classes.  A datum is *really* an experimental condition PLUS
a measurement.  This type of interpretation maps directly onto the
suggested enhancement of enumerations.