Enum "Inheritance"?

[spir]

On 02/27/2011 04:20 AM, Nick Sabalausky wrote:
> "Nick Sabalausky"<a at a.a>  wrote in message
> news:ikcepj$248p$1 at digitalmars.com...
>>
>> I think your main original problem was that there isn't really a way to
>> compose enums additively, only subtractive.
>>
>
> That just gave me an idea: I think you should be able to get away with an
> ordinary union:
>
> enum STD {
>      STD_ELEMENT_1 = 17,
>      STD_ELEMENT_2 = 42,
> }
>
> enum AOnly {
>      A_ACCESS_1 = 0x80,
> }
>
> enum BOnly {
>      B_ACCESS_1 = 0x80,
> }
>
> union A {
>      STD std;
>      A a;
> }
>
> union B {
>      STD std;
>      B b;
> }
>
> void funcA(A a) {
>      if(a.a == A_ACCESS_1) {}
>      if(a.std == STD_ELEMENT_1) {}
> }
>
> void funcB(B b) {
>      if(b.b == B_ACCESS_1) {}
>      if(b.std == STD_ELEMENT_1) {}
> }
>
> In the general case, I'd be very hesitent to use a non-tagged union like
> this, because it wouldn't provide protection against accidentally having the
> same integer value for a member of STD and a member of A or B (which would
> obviously screw the whole thing up). But in your paricular case it doesn't
> seem that would likely be an issue.
>
> Of course, if you dodn't mind a heavier-weight OO-based solution, you could
> always use classes instead of enums and use static immutable class members
> as the possible values (and make the constructor private to prevent
> additional possible values), but personally I think that would be
> over-engineered compared to either the above or the mixin solution in my
> previous message.

Very interesting solution, indeed: enum composition via union. I think as well 
it's safe because --per definition-- each 'code' of a discriminating enum must 
have a distinct value. (They are nominals: 
http://en.wikipedia.org/wiki/Nominal_number).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com