rfg@lupine.ncd.com (Ron Guilmette) (05/25/91)
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.richard@stat.tamu.edu (richard.henderson~) (05/26/91)
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~
rae@alias.com (Reid Ellis) (05/26/91)
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]
davidm@uunet.UU.NET (David S. Masterson) (05/27/91)
>>>>> 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!"bevan@cs.man.ac.uk (Stephen J Bevan) (05/28/91)
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
gregk@cbnewsm.att.com (gregory.p.kochanski) (05/30/91)
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.