Open lloydmeta opened 7 years ago
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.
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:
@daniel-shuy has submitted the following design:
would expand to: