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
Public Overridable Sub DoSomething(ByVal e As SomeEnum)
Select Case e
Private Sub DoSomething1()
Private Sub DoSomething2()
Public Class DerivedClass
Public Shadows Enum SomeEnum
Public Shadows Sub DoSomething(ByVal e As SomeEnum)
Select Case e
Case SomeEnum.Value1, SomeEnum.Value2
Private Sub DoSomething3()
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:
and then try to extend it with inheritance like so (this is not legal):
Enum FooDerived Inherits Foo
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.