Open ybasket opened 1 year ago
Nice, thanks for bringing this up.
I don't have a hard stance about not making the two compatible, but I do have to wonder about the use case of mixing Scala 3 enums with enumeratum (fwiw I think this wouldn't have worked with Scala 2 either?).
Once we understand that, then we can better discuss whether this is something worth putting in the effort to debug and fix.
I don't have a hard stance about not making the two compatible, but I do have to wonder about the use case of mixing Scala 3 enums with enumeratum (fwiw I think this wouldn't have worked with Scala 2 either?).
And I don't have a hard stance on that it should be possible to mix both, but I see some advantages:
sealed trait
enum
, so it can help the adoption of this library to support itenum
If there's no good way of integrating, I would at least suggest to add a note in the docs as the error can be a bit puzzling for people not familiar with Scala compilation internals.
All valid points.
I think the biggest barrier is, as you found, the values: Array[_]
that Scala 3 emits : I understand it's probably for Java compat, but I'd rather not have Enumeratum move to that; besides being a bit low-level, emitting a new array is necessary in order to be "safe" (otherwise callers can mutate the thing!).
Not exactly sure where that leaves us, but I'll leave this issue open to see if someone interested (are you?) can take up the challenge of integrating the two.
Yeah, I'm surprised they didn't make it an IArray
(Scala 3's immutable wrapper type for arrays) at least.
I would be interested in trying to fix this in general (experimented a bit yesterday), but my OSS bucket list is considerably long already, so I don't expect to pick up this any time soon. So whoever reads this, feel invited to pick it up.
I don't have a hard stance about not making the two compatible, but I do have to wonder about the use case of mixing Scala 3 enums with enumeratum
There's really a use-case. It helps get rid of the need to implement custom codecs every time.
Like, when we use enums in data models, for instance, for JSON responses from some API, or in databases, Enumeratum is super handy. We can have friendly names for each option, but at the same time, we can define keys that match with an external data source. It'll be easier to get what I mean with a code example.
enum TransportMode(id: String): // I need Enumeratum here to make this work (automatically)
case Truck extends TransportMode("TRK")
case Vessel extends TransportMode("SHP")
case Airplane extends TransportMode("AIR")
case Rail extends TransportMode("TRN")
Thanks to Enumeratum, I can go with StringEnum
and deserialize data using the value in id
, while still using friendly names in my code. So, I don't have to create an enum with weird values like below and use them in my code. I just want to use them for mapping data.
enum TransportMode:
case TRK, SHP, AIR, TRN // unfriendly names that also don't fit the code conventions
And yeah, without Enumeratum, I could achieve the goal by implementing a custom codec. But the cool part is that with Enumeratum, I just elegantly define this mapping, and that's it. No need to write any boilerplate code for a custom codec, or access the id
manually in a mapper.
Another use case is when the external source uses screaming case. That's where I'd use with Lowercase
as in the example from the first comment. The external system would send in JSON values like BLACK
, COLOURFUL
, but in my code, I can stick to my style guide and have Black
and Colourful
.
Continuing from the previous explanation and summarizing the motivation:
After switching to Scala 3, I want to implement my enums slickly using the enum syntax, instead of mixing up conventions. Like, not sometimes using a sealed trait with the whole Scala 2 style (where I want to use Enumeratum), and other times enum
. I just want to have consistent conventions throughout the project and always use enum
.
I hope the above motivation is convincing enough that Enumeratum is still needed, even though Scala 3 has enum now. It's about making that enum
be on steroids.
I don't expect to pick up this any time soon. So whoever reads this, feel invited to pick it up.
Bumping this, need help.
First of all, very cool that enumeratum made it to Scala 3, thank you to all people involved!
A coworker of mine found an issue though that seems worth fixing – you can't use enumeratum on Scala 3 enums due to a naming conflict:
results in an error:
Removing
values
also doesn't work as Scala 3 generates avalues
method that is backed by anArray
(which is noIndexedSeq
).Now, one could legitimately question whether you need to mix both, but I think it would be nice if that was possible. As the compiler suggests, a
@targetName
(which would rename enumeratum'svalues
on byte code level) could be enough to fix it. Or are there are good arguments on why interop should be forbidden and people forced to use the more verbosesealed trait
syntax? I couldn't find anything on the PR for Scala 3 support.There's a workaround involving a bit of boilerplate (I didn't test it 100% yet though, it may have issues):
Scastie for demonstration: https://scastie.scala-lang.org/kJLNLIaRQPWtqjgwDs4B1g