Non-literal values for ValueEnums don't work. about enumeratum HOT 3 CLOSED

I suppose it's worth noting that it's not the intermediate class so much as the intermediate constructor that's doing it. This works, for example:

abstract class StringEntryWithHelpers extends StringEnumEntry {
  //...
}


sealed abstract class Parameter(val value: String) extends StringEntryWithHelpers
object Parameters extends StringEnum[Parameter] {
  object FOO extends Parameter("foo")

  override def values = findValues
}

I'd hoped to hide the "val value" requirement was all.

from enumeratum.

Unfortunately, there is currently a strict requirement to have the value member of all of these value enums be implemented as a literal, in order for us to do the uniqueness check. There might be a way to sling enough macro magic to support what you're proposing (look up the class hierarchy to resolve that value is being implemented by a name member that is supplied as a literal at instantiation), but it seems like it'll be very difficult, and perhaps error-prone due to edge cases.

from enumeratum.

Alright, I'm using the phrasing in my second comment, I was just a little concerned that the "val value" was a bit of magic future maintainers might not notice. It's hard to decide between

sealed abstract class Parameter(val value: String) extends StringEnumEntry
// with
object FOO extends Parameter("foo")

and

sealed abstract class Parameter extends StringEnumEntry
// with
object FOO extends Parameter { val value = "foo" }

Not a huge deal either way though.

from enumeratum.