Skip to content
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

Sleeker API #112

Open
lloydmeta opened this issue Feb 6, 2017 · 3 comments
Open

Sleeker API #112

lloydmeta opened this issue Feb 6, 2017 · 3 comments

Comments

@lloydmeta
Copy link
Owner

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)
}
@lloydmeta
Copy link
Owner Author

Any design should take into consideration the design proposed here scala/scala3#1970

@LPTK
Copy link

LPTK commented Feb 27, 2017

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.).

@LPTK
Copy link

LPTK commented Feb 27, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants