A Note about Enums (Scott Wisniewski)

I recently received an email from a customer who had a few questions about “enum inheritance” in VB, specifically as to why it wasn’t supported. In particular, he sent us the following snippet of VB code (I’ve changed the names of the classes and methods involved) :

Option Strict On

Public Class BaseClass

    Public Enum SomeEnum
        Value1
        Value2
    End Enum

    Public Overridable Sub DoSomething(ByVal e As SomeEnum)
        Select Case e
            Case SomeEnum.Value1
                DoSomething1()
            Case SomeEnum.Value2
                DoSomething2()
        End Select
    End Sub

Private Sub DoSomething1()
End Sub

Private Sub DoSomething2()
End Sub

End Class

Public Class DerivedClass
Inherits BaseClass

    Public Shadows Enum SomeEnum
        Value1
        Value2
        Value3
    End Enum

    Public Shadows Sub DoSomething(ByVal e As SomeEnum)
        Select Case e
            Case SomeEnum.Value1, SomeEnum.Value2
                MyBase.DoSomething(CType(e, BaseClass.SomeEnum))
            Case SomeEnum.Value3
                DoSomething3()
        End Select
    End Sub

Private Sub DoSomething3()
End Sub

End Class

and asked us the following questions:

Why does SomeEnum have to be marked as shadows inside DerivedClass? Why can’t I use “overloads”?
Why does DerivedClass.DoSomething() have to cast it’s enum value to the value in the base class.

I figured other people may have run into similar issues any may have some of the same questions, and so though this would make a good blog post.

My response is below:

VB does not support “Enum” inheritance, and so it is not possible for one Enum type to inherit from another “Enum” type.

This is mainly because “Enum” inheritance is not safe. In general, an inheritance relationship between two types implies that it is possible to always treat a “more specific” derived class as if it was also a “more general” base class. This relationship does not hold between two enums.

This is because, enum’s are really not object-oriented concepts. Instead, an enum is just a collection of constant variable declarations conveniently packaged into a type. What defines the “identity” of an enum is the set of values it may take.

In general, if you were to take an enum like so:

Enum Foo 
    Value1 
    Value2
End Enum

and then try to extend it with inheritance like so (this is not legal):

Enum FooDerived Inherits Foo 
    Value3
End Enum

It would no longer be possible to say that “any FooDerived” is also a “Foo”. This is because the value “Value3” cannot be treated as if it was a “Foo” value.

The compiler does, for convenience, provide conversions between different enum types. This is because in the event that you know the value your are converting can be represented in the target type then it is safe to do the conversion. Because it is not always safe, however, the conversion is treated as a “narrowing” (unsafe) conversion rather than a “widening” (safe) conversion.

When “option strict” is turned on the compiler will not implicitly perform unsafe conversions. Instead it requires you to explicitly tell it when a potentially unsafe conversion is in fact safe by writing an explicit “CType”.

Marking the SomeEnum type DerivedClass as shadows makes it a completely new enum type from the one defined in “BaseClass”. Because “BaseClass.SomeEnum” and “DerivedClass.SomeEnum” are different enum types, the conversion is not safe, and thus requires an explicit cast.