Sleeker API
As raised in #109, it might be a good idea to brainstorm some ways to make Enumeratum's API sleeker and nicer to use in the future.
Some unfiltered thoughts:
- Let's not worry about breaking backwards compatibility for now.
- Let's aim at using Scalameta for future-proofing and the prospect of better IDE compatibility
- Practically speaking, my experience is that the size and complexity of the macro grows non-linearly with every feature (language level) you want to support. The difficulty balloons even more when concise syntax is also a goal.
- API should be simple and easy to understand
@daniel-shuy has submitted the following design:
@Enum(CapitalWords)
sealed abstract class Grocery(
@EnumKey(unique = true) // should unique default to true/false?
id: Int,
@EnumKey(unique = false) // should unique default to true/false?
category: String,
exampleBool: Boolean
)
object Grocery {
case object Chicken extends Grocery(101, "Meat", true)
case object Lamb extends Grocery(102, "Meat", false)
// case object Pork extends Grocery(102, "Meat", true) <-- will fail to compile because the id 102 must be unique
case object Coke extends Grocery(201, "Beverage", false)
}
would expand to:
sealed abstract class Grocery(id: Int, category: String, exampleBool: Boolean) extends EnumEntry with CapitalWords
object Grocery extends Enum[Grocery] {
case object Chicken extends Grocery(101, "Meat")
case object Lamb extends Grocery(102, "Meat")
case object Coke extends Grocery(201, "Beverage")
val values: immutable.IndexedSeq[Grocery] = IndexedSeq(Chicken, Lamb, Coke)
private val idToEntriesMap: immutable.Map[Int, Grocery] =
Map(
Chicken.id -> Chicken,
Lamb.id -> Lamb,
Coke.id -> Coke
)
private val categoryToEntriesMap: immutable.Map[String, Set[Grocery]] = ??? // some MultiMap implementation (Scala's MultiMap seems lacking...maybe Google Guava's HashMultimap?)
def withId(id: Int): Grocery = idToEntriesMap(id)
def withCategory(category: String): Set[Grocery] = categoryToEntriesMap(category)
}
Any design should take into consideration the design proposed here https://github.com/lampepfl/dotty/issues/1970
Hello there, just chiming in (a little late, sorry). I'm quoting the previous, closed issue on the same subject:
One thing I've seen quite often with the annotation-driven enum solutions is that they exchange power/flexibility in exchange for terseness. What this means is that they usually don't support the full myriad of things that Scala allows you to do, like adhock extend other traits/classes in members (e.g. the way we do stacked traits to manipulate names) or add methods and values to each member, which can come in quite handy. By the time you can support all these use-cases, you've probably got a fairly huge and complex macro.
In case you have not seen it yet, I designed a powerful macro-annotation library to express sealed class hierarchies more easily in Scala: boilerless.
Its focus is only on reducing boilerplate, which is orthogonal to the issue of defining enums, so it is completely compatible with enumeratum. I even added a dedicated syntax to make it terser to define enumeratum enums. Have a look here.
On the other hand, it does not remove any flexibility compared to what you can do with Scala (add members, explicit extends clauses, etc.).
Note: despite that, the library is still rather simple, consisting of a single file with 325 LOC (excluding blanks and comments). The logic is admittedly rather complex and the code could be clarified, but there is nothing fundamentally complex about it.