Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Mikhail Nemenko
    @eniqen
    Hi is there any chance to have fallback in enumeratur circe ?
    Igor Tovstopyat-Nelip
    @igortn

    I am trying to write a polymorphic function that would return an optional enum entry. Something along these lines:

    def f[T <: Enum[_]](s: String): Option[T] = T.withNameOption(s)

    And, the above will not work. Anybody has an idea how this should be done correctly?

    Igor Tovstopyat-Nelip
    @igortn
    Ok, found the solution:
    def f[T <: EnumEntry: Enum](s: String) = implicitly[Enum[T].withNameOption[T]
    Matt Dziuban
    @mrdziuban
    would a pull request be accepted to include objects defined inside objects in the companion object? e.g.
    sealed trait Thing extends EnumEntry
    
    object Thing extends Enum[Thing] {
      case object Foo extends Thing
    
      object other {
        // not currently included in values
        case object Bar extends Thing
      }
    }
    Ender Tunc
    @endertunc_gitlab

    Hey all, I have a quick question.
    I am passing enum to doobie and it does not seem to be using entryName.
    I have the following:

        println(s"ENUM: ${enum.entryName}")
        val fragment: Fragment = fr"........ ORDER BY $enum"

    I expect LowerCamelcase and println works as expected but value passed to doobie does not. Am I doing something wrong here?

    volgad
    @volgad

    Hi All, I have a question regarding using Enumeratum. I have used it for a while and thought it was really a usefull add on to scala. I have an akka stream system that I am moving to akka cluster. In order to pass messages, I use Jackson and I found very hard to make the EnumEntry serializable. The reasons being

    1) th enecessity to pass a made up Type for the the enum entries in the following (because it needs to be a class not a type like object)
    @JsonSubTypes(
    Array(new JsonSubTypes.Type(value =

    2) The reverse serialization of the object with

    @JsonTypeInfo(
    use = JsonTypeInfo.Id.NAME,
    property = "type",

    visible = true
    )

    I also tried to use implicit val formats: Formats = DefaultFormats + Json4s.serializer() as suggested on git enumeratum

    I eventually made it work by turing my case object into a final case class. Does anybody have a pointer or reference / example oin how to make this work? Thank you
    vonchav
    @voonchav_gitlab
    Hi all, the core enumeratum (as well as the circe module) has been updated to 1.6.1. The enumeratum-quill module remains at 1.6.0. Does it need to be upgraded to 1.6.1 too? Or is the point version bump not relevant to the enumeratum-quill module? I use one version variable in sbt for all my enumeratum modules . Just wondering.
    Diego E. Alonso Blas
    @diesalbla
    @lloydmeta Similar to the question above: are now all packages of enumeratum to be kept and released on same version numbers, going on?
    Adrian
    @adrian-salajan

    Hi, i would like to have encoder for something like this:

    sealed trait MainType
    class MainA extends MainType
    class MainB extends MainType
    
    sealed abstract class Subtypee[_ <: MainType](override val entryName: String) extends EnumEntry
    
    object Subtypee extends Enum[Subtypee[_]] with CirceEnum[Subtypee[_]] {
    
      def values = findValues
    
      case object A1 extends Subtypee[MainA]("A1")
      case object A2 extends Subtypee[MainA]("A2")
    
      case object B1 extends Subtypee[MainB]("B1")
      case object B2 extends Subtypee[MainB]("B2")
    }
    
    import io.circe.syntax._
    import io.circe._
    import io.circe.Json
    import io.circe.generic.semiauto._
    
    println(">>>>>>>>>>>>>" + Subtypee.A1.asJson)

    but i get

     could not find implicit value for parameter encoder: io.circe.Encoder[com.ing.raptor.generic.cloudEvents.mom.Subtypee.A1.type]
    Adrian
    @adrian-salajan
    ^i redesigned having one separate enum for each subtype
    Gavin Bisesi
    @Daenyth

    :wave: I'm wondering if I can make an inductive implicit for any Enum?

    I have an implicit def stuff[E <: EnumEntry]: otherLib.FromStringStuff[E] = str => Enum.materializeEnum[E].withName(str)
    But the macro fails with Could not find the companion object for type type E.

    I also tried giving it a ClassTag implicit in case that would help satisfy the WeakTypeTag, but it still fails
    Gavin Bisesi
    @Daenyth
    :eyes: Actually, is there a reason Enum doesn't provide implicit val fooEnum: Enum[A] = this onto the companion?
    ah I think it worked when I changed it to implicit def stuff[E <: EnumEntry: Enum]...
    that probably got the materialize macro into the right location to have a fixed name to search for
    Diego E. Alonso Blas
    @diesalbla
    Good morning !
    We are curious: what are the plans for the enumeratum library re: Scala 3, a.k.a. dotty?
    The Dotty docs refer to an apparently easier syntax for enum values in http://dotty.epfl.ch/docs/reference/enums/enums.html,
    but I am not sure if the problems addressed by enumeratum are fixed in there...
    Also, I understand that enumeratum depends on some macro code as well, to generated the methods. Is there a plan to port that to the new MetaProgramming of Scala 3?
    Gavin Bisesi
    @Daenyth
    Can't speak for the enumeratum devs, but I believe most of what enumeratum addresses won't be a problem in scala3 enums.
    Diego E. Alonso Blas
    @diesalbla
    Well, I was asking two different questions:
    1) Could enumeratum become no longer needed, because Scala 3 enums provide those features?
    2) Would there be a problem to re-implement enumeratum macro code on Scala 3?
    Luís Campos
    @LLCampos
    @lloydmeta, following up from the above: what are the plans regarding Scala 3? :)
    Lloyd
    @lloydmeta

    Good question.. from what I've seen of the Scala 3 enums, I think it might not be necessary to implement the core macro in Scala 3.

    I haven't taken a look lately, but IIRC the whole metaprogramming toolkit has been completely revamped in Scala 3, so while possible to port the macro in some form, it would be a substantial rework.

    If anything, I would want to see what kind of needs (complaints :D) people have with Scala 3 enums before trying to fit enumeratum into Scala 3.

    Gavin Bisesi
    @Daenyth
    For me the main thing would be - if we can hit source compatibility between the scala2 and scala3 bases, or even just mostly source compatibility, that's all I care about
    I just want to be able to cross-publish when the time comes
    George
    @westwater

    @lloydmeta Similar to the question above: are now all packages of enumeratum to be kept and released on same version numbers, going on?

    Would love to get an answer to this, some of the extension modules are out by a patch version

    Henri Cook
    @henricook
    Hi all, I was just looking for release notes between 1.6.1 and 1.6.2 - do they get published somewhere?
    Denis Novac
    @DenisNovac
    Hi everyone. I am getting some troubles with CirceEnum[_]. Does it support case classes with fields? For example, MyType(field: String)? It seems that it only converts it to json string "MyType("something")"
    Sergey Torgashov
    @satorg
    @DenisNovac you probably need StringCirceEnum for that (which requires StringEnum and StringEnumEntry rather than Enum and EnumEntry.
    Denis Novac
    @DenisNovac
    @satorg perhaps, you misunderstood my question. I want to get valid json like {"field" : "test"} instead of json string MyType("test").
    Sergey Torgashov
    @satorg
    @DenisNovac yes, seems I did. Would you provide a more complete example please – a model you're going to serialize and a JSON you'd like to get?
    Denis Novac
    @DenisNovac
    @satorg something like this
    import enumeratum.{CirceEnum, Enum, EnumEntry}
    import io.circe.generic.extras.Configuration
    import io.circe.syntax._
    
    sealed trait TestValues extends EnumEntry
    
    object TestValues extends Enum[TestValues] with CirceEnum[TestValues] {
    
      final case class MyType(name: String) extends TestValues
    
      override def values: IndexedSeq[TestValues] = findValues
    
      implicit val config: Configuration = Configuration.default.withDiscriminator("type")
    
    }
    
    val something: TestValues = TestValues.MyType("hello")
    
    something.asJson.spaces2
    // invalid json: "MyType(hello)"
    
    // expected json: {"type": "MyType", "name": "hello"}
    I am not sure if CirceEnum supposed to do this. I still can get this behavior from vanilla scala ADT + circe derivation though.
    Sergey Torgashov
    @satorg

    @DenisNovac yes, you're right. I'd say, the enumeratum itself is not supposed to do this – to handle case classes as entries.

    vanilla scala ADT + circe derivation though.

    I guess you've found some solution already. But basically yes, as one option, there could be some regular case class for TestValues which might include typefield of MyType enum type as a discriminator.

    Ben Plommer
    @bplommer
    Does anyone else get this error trying to compile Enumeratum enums in Scala 3 with cross building?
    [error] Found:    Seq[scala.annotation.Annotation]
    [error] Required: Array[String]
    Sergey Torgashov
    @satorg
    Hi guys. I have been looking at enumeratum-cats module and surprisingly haven't found an implicit Order in CatsEnum.
    I believe it could be as simple as Order.by(indexOf) – i.e. keep entries arranged in the order they're defined.
    But I'm wondering – is there any reason why not to define a default order in this way?
    Gregg Hernandez
    @gregghz
    there are probably other sensible orderings as well (alphabetical, for example) -- I'd guess you'd at least want a way for the user to pick how they want their items ordered
    Ryan Heins
    @RyanHeins

    Hi everyone. I'm trying to use Enumeratum to define a set of errors that have an error code and error message. I would really like to have the option to have different error messages for a single error code like this:

    sealed abstract class Failure(val value: Int, val message: String) extends IntEnumEntry {}
    
    object Failure extends IntEnum[Failure] {
      val values = findValues
    
      case object UnexpectedError extends Failure(value = 1, message = "unexpected error")
    
      case object MissingRequiredInput extends Failure(value = 2, message = "Missing required input")
      case class MissingRequiredInput(name: String) extends Failure(value = 2, message = s"Missing required input: $name")
    }

    and this compiles fine, but it seems findValues only finds case objects and not case classes. Does anyone know if what I'm trying to do is possible?

    Or if there is a solution to have just the case class MissingRequiredInput and not the case object, that would also be awesome.
    Ian Pojman
    @ianpojman

    trying to add scala 3 support to my codebase that uses enumeratum. I did see that scala 3 support is in progress per lloydmeta/enumeratum#300.

    In the meantime, what are the recommendations, if any, to support both scala 2 and scala 3 builds in codebases that use enumeratum? do i need to have two source versions of the enum for 2.x vs 3.x ? I was hoping I could just use a scala 3 enum and have it magically cross compile into scala 2.x but im not sure if that works...

    Thanks for the library, enumeratum made life much easier in scala 2.

    Brendan Maguire
    @brendanmaguire
    Are there plans to cut a release of enumeratum in the short to medium term? The last release was almost a year ago (https://github.com/lloydmeta/enumeratum/releases/tag/v1.7.0) and some of the dependencies in that release are quite out of date (I'm particularly interested in Doobie 1.x support).
    Lloyd
    @lloydmeta
    Releases are done when there's a need, mostly driven by PRs :) Specifically for the doobie integration, one was released not too long ago after https://github.com/lloydmeta/enumeratum/pull/338/files was merged.
    Brendan Maguire
    @brendanmaguire
    Ah, thank you @lloydmeta . I didn't realise there was a different release cadence for the core and non core packages :)
    Artavazd Balaian
    @REASY
    Hello. Is there a nice way to overcome lloydmeta/enumeratum#346 Thanks
    jnicoulaud-ledger
    @jnicoulaud-ledger

    I don't understand how to create ByteEnum, this code:

    import enumeratum.values.{ByteEnum, ByteEnumEntry}
    
    sealed abstract class MyEnum(val value: Byte) extends ByteEnumEntry
    
    object MyEnum extends ByteEnum[MyEnum] {
    
      val values: IndexedSeq[MyEnum] = findValues
    
      case object ONE extends MyEnum(0x01.byteValue)
      case object TWO extends MyEnum(0x02.byteValue)
    }

    does not compile:

    It looks like not all of the members have a literal/constant 'value:int' declaration, namely: object ONE, object TWO.
    This can happen if:
    - The aforementioned members have their `value` supplied by a variable, or otherwise defined as a method
    If none of the above apply to your case, it's likely you have discovered an issue with Enumeratum, so please file an issue :)
    val values: IndexedSeq[MyEnum] = findValues
    Lloyd
    @lloydmeta

    enumeratum.values._ require all values to be passed as literals in order to do the compile-time uniqueness check.

    In your case, you need to drop .byteValue and just use case object ONE extends MyEnum(0x01)

    jnicoulaud-ledger
    @jnicoulaud-ledger
    oh, ok, that works, thanks
    jnicoulaud-ledger
    @jnicoulaud-ledger
    the issue with that is that it only works for small values, eg for 0xf0 you have to replace with the decimal value :s
    Couldn't we improve findByteValueEntriesImpl to look for both Int and Byte ? I can do a PR when I get time
    Shah Saraei
    @ShahOdin

    What's the nicest way of adding "scope" to an enum? consider:

    sealed trait Foo
    sealed trait FooBar extends Foo
    object FooBar{
      case object First extends FooBar
    }
    sealed trait FooBaz extends Foo
    object FooBaz{
      case object First extends FooBaz
    }

    by default, if I define Foo as an Enum, the circe support wont be able to distinguish FooBar.First and FooBaz.First. I understand I could use discriminators but that would not be desirable as it would turn the serialised values into jsons, right? Is there a nice and sweet way of having a hierarchy within my enums, as described aboe?

    CodingPenguin
    @TheCodingPenguin

    Hello everyone I have a weird case happening. Here is the basic snippet I re-created

    sealed trait FirstEnum extends EnumEntry
    
    sealed abstract class SecondEnum(val id: Int) extends EnumEntry
    
    object FirstEnum extends Enum[FirstEnum] {
        val values = findValues
    
        object SecondEnum extends Enum[SecondEnum] {
            val values = findValues
    
            case object MyEnum extends SecondEnum(id = 1) with FirstEnum
            case object AnotherEnum extends SecondEnum(id = 2) with FirstEnum
            case object YetAnotherEnum extends SecondEnum(id = 3)
    
        }
    
    }
    
    FirstEnum.values --> Vector(MyEnum, AnotherEnum)
    SecondEnum.values --> Vector(null, AnotherEnum, YetAnotherEnum)

    For some reason the first extending object is returned as null. Am I doing something wrong by creating this structure? I want to make use of findValues functionality and find different types of classes extending different enums.