-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Enum extends another enum #4961
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I think the enum is the same. |
We don't seem to have tests for enums that extend enums; it seems to only work in part, and by accident (at least in 0.9.0-RC1). We only test that case classes can't extend enums. object enumTest {
enum Test {
case A
case B
case C
}
enum Test2 extends Test {
case D
}
def testUser(t: Test): Unit = {
t match {
case Test.A =>
case Test.B =>
case Test.C =>
case Test2.D => //
}
}
def test2User(t: Test2): Unit = {
t match {
case Test2.D => //
}
}
def main(args: Array[String]) = {
println(Test.enumValues) // MapLike.DefaultValuesIterable(A, B, C)
println(Test2.enumValues) // MapLike.DefaultValuesIterable(D)
}
} Here, a We provide final case val A: playground.enumTest.Test =
playground.enumTest.Test.$new(0, "A")
final case val B: playground.enumTest.Test =
playground.enumTest.Test.$new(1, "B")
final case val C: playground.enumTest.Test =
playground.enumTest.Test.$new(2, "C")
//...
final case val D: playground.enumTest.Test2 =
playground.enumTest.Test2.$new(0, "D") |
Consensus from our weekly meeting is, enums are not meant to support this — they're a special case of case classes. We should add a compiler error for enums extending enums. Other encodings might be possible; for instance: trait Prefix {
type EnableD
enum Test {
case A
case B
case C
case D(erased implicit ev: EnableD =:= Any)
}
}
object NoD extends Prefix { type EnableD = Nothing }
object WithD extends Prefix { type EnableD = Any } |
I think it is good to not allow enum extend another enum. So, now if I want to achieve something similar to my example in the first comment I can code as follows:
Now A and B both are children of AA and the companion of AA gives the effect of giving both the A's and B's enum values as AA types. The enum extends enum could give the illusion that parent enum has child enum's values. This could be confusing for a newbie of Dotty. But now with this above code, it is explicit that A and B are children of AA. |
Seems we're set. I opened a smaller issue (#5008) to actually forbid the scenario; I'm closing this one but let us know (even here) if you see anything else to do on this. |
We are currently using Enumeratum library to have enums in our code base. In a particular use case, we have a requirement such as there is inheritance in the behavior of enums for e.g.
As one would have noticed in the above code, FullAlarmSeverity companion object has values manipulated to also append the AlarmSeverity values, so that Okay from AlarmSeverity can also be deserialized to FullAlarmSeverity.
Using enums instead of ADT gives us the advantage of using
withName
andvalues
methods. But trying to achieve something similar with Dotty seems pretty difficult.So, is there any way to do so in Dotty with Enum or is there any other pattern that can give us the same effect of inheritance along with the advantage of
withName
andvalues
methods from Enumeratum ?The text was updated successfully, but these errors were encountered: