Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    George
    @giannoug
    Hello @lloydmeta! I've used a type annotation. If that helps I've also tried inSet with exactly the same results, e.g. partQuery.filter(p => p.category inSet Nil). Is there any specific piece of code you might be interested in?
    Lloyd
    @lloydmeta
    I think it would be helpful to see the code surrounding where you're trying to do the filtering. I'm in particular wondering if the type mapper is in scope.
    Might be easiest to throw up a small repro on Github that you can share :)
    this is for slick 2 so the error talks about Column instead of Rep but the answer looks relevant https://stackoverflow.com/a/30485093/1814775
    The asker initially had value =!= is not a member of scala.slick.lifted.Column[Status] [error]
    Derya Aydede
    @Derya
    hi! can my enum class have a type parameter? so I end up with case object Foo extends Enum[Foo[_]] { ...
    Lloyd
    @lloydmeta
    Works on my end in Ammonite
    @ import $ivy.{`com.beachape::enumeratum:1.5.13`}
    @ {
      sealed trait MyEnum[T] extends EnumEntry
    
      object MyEnum extends Enum[MyEnum[_]] {
        case object One extends MyEnum[Int]
        case object Two extends MyEnum[Boolean]
        val values = findValues
      }
    
      }
    defined trait MyEnum
    defined object MyEnum
    
    @ MyEnum.values
    res6: collection.immutable.IndexedSeq[MyEnum[_]] = Vector(One, Two)
    Derya Aydede
    @Derya
    yeah I got it working too, awesome thanks
    probably should have mentioned, sry about that
    Elijah Rippeth
    @erip
    Hi all. I have a question. I have a library that I've developed using enumeratum and enumeratum with play-json support.
    I have something like
    sealed trait Foo with StringEnumEntry {
      def value: String
    }
    
    // ...
    
    case object Foo extends StringEnum[Foo] with StringPlayJsonValueEnum[Foo] {
      // ...
    }
    I'm wondering how I can not marry this so closely with play-json; i.e., how can I let others pick their own serializers assuming enumeratum supports it?
    Lloyd
    @lloydmeta

    If you look at how StringPlayJsonValueEnum is declared in https://github.com/lloydmeta/enumeratum/blob/bc76d2be1936cd13641cae491489de48b2af425d/enumeratum-play-json/src/main/scala/enumeratum/values/PlayJsonValueEnum.scala#L48-L51

    You'll see that it's just a simple wrapper around calling enumeratum.values.EnumFormats.formats :)

    This means that inheritance of it is not necessary; you can simply do case object Foo extends StringEnum[Foo], then summon a Play-JSON formatter for it (could be in another module or at the site of Json.toJson) by doing implicit val fooEnumFormatter = EnumFormats.formats(Foo)

    Elijah Rippeth
    @erip
    OK, so the bottom line is that one should only pull in the enumeratum-${serialization-lib}once they know exactly which library they want to use.
    Lloyd
    @lloydmeta
    in a nutshell, yes.
    Elijah Rippeth
    @erip
    thanks, Lloyd. I love the library. :raised_hands:
    Stan Domeshok
    @sdomeshok
    Hey folks, trying to make a function that can synthesize an enum value from a string, this is the type I'm ending up with and it feels on the verbose side. Is there some easier way I can cut it?
    def makeEnum[A <: EnumEntry, E <: Enum[A]](value: String, enumType: E): Option[A]
    needing enumType: E for access to withLowerCaseOption
    Lloyd
    @lloydmeta

    I would maybe take advantage of the fact that there's a macro that materialises Enum[Entry].. so

    def makeEnum[Entry <: EnumEntry: Enum](s: String): Option[Entry] = implicitly[Enum[Entry]].withNameOption(s)

    Usage:

    @ import $ivy.`com.beachape::enumeratum:1.5.13`, enumeratum._
    import $ivy.$                                , enumeratum._
    
    @ {
      sealed trait Greeting extends EnumEntry
    
      object Greeting extends Enum[Greeting] {
    
        val values = findValues
    
        case object Hello   extends Greeting
        case object GoodBye extends Greeting
        case object Hi      extends Greeting
        case object Bye     extends Greeting
    
      }
      }
    defined trait Greeting
    defined object Greeting
    
    @ def makeEnum[Entry <: EnumEntry: Enum](s: String): Option[Entry] = implicitly[Enum[Entry]].withNameOption(s)
    defined function makeEnum
    
    @ makeEnum[Greeting]("Hello")
    res3: Option[Greeting] = Some(Hello)
    Stan Domeshok
    @sdomeshok
    Ah! Thank you! @lloydmeta -- I was looking for an Enum typeclass and couldn't find one. Should have read the docs more carefully!
    Nicolas Rinaudo
    @nrinaudo
    Is there a version of enumeratum-scalacheck compatible with scalacheck 1.14.0?
    Nicolas Rinaudo
    @nrinaudo
    from what I can tell:
    • no
    • but that's just because it's not been released, enumeratum uses scalacheck 1.14.0
    if I were to confirm it works (by releasing locally on a project that fails because of enumeratum), could you consider a release?
    Georgy Davityan
    @implmnt
    Hi, is it possible to generate full entry names with enumeratum?
    e.g.
    sealed trait X extends EnumEntry
    object X extends Enum[X] {
      val values = findValues
    
      sealed trait Y extends X
      object Y {
        case object A extends Y
        case object B extends Y
      }
    }
    
    import X.Y._
    A.entryName // == "X.Y.A"
    B.entryName // == "X.Y.B"
    Dermot Haughey
    @hderms
    is there a way to make a circe decoding failure tell you the possible enums you should choose from?
    Anthony Garo
    @agaro1121
    Hi
    Is there a way to provide a default case i.e Unknown ?
    Anthony Garo
    @agaro1121

    I could do something like:

    trait WithFallBack[A <: EnumEntry] {
      self: Enum[A] =>
      def withNameAndFallback(name: String): A
    }

    Just wondering if this exists already

    Dermot Haughey
    @hderms
    I'm guessing Enumeratum enums compare very favorably with strings when it comes to things like memory usage and equality comparisons. is this correct?
    is the memory cost for using an Enum basically like a pointer per 'instance' of the enum
    • the overhead of storing it in the first place
    Lloyd
    @lloydmeta
    there's also additional overhead of keeping bigger lookup maps for each instance of the enum, but roughly I think your hunch is spot on.
    Dermot Haughey
    @hderms
    is it possible to have aliases of enums?
    Dermot Haughey
    @hderms
    i manually implemented it for a specific use case
    i suppose Eq typeclass or something is another way to do it
    Lloyd
    @lloydmeta
    can you elaborate? what would be an instance ofan enum?
    like a type alias?
    Dermot Haughey
    @hderms
    I guess you could say it would be multiple entryName mapping to the same Enum
    Lloyd
    @lloydmeta
    ah, no sorry that is not supported atm.
    Ben Stewart
    @bastewart
    Hi! Sorry to be a needy end-user but would it be possible to release a version of enumeratum-circe which depends on Circe 0.12.1? I think everything is merged so it could be released. Thank you!
    Lloyd
    @lloydmeta
    It could be, but AFAIK 0.12.1 is source-and-binary compatible with 0.12, so you could just add a dependency on that version of Circe instead and sbt/maven/ivy should pick the latest version and "just work"? unless if I'm missing something.
    Travis Brown
    @travisbrown
    @lloydmeta I’m not at a computer at the moment, but iirc the latest enumerating-circe release depends on a circe 0.12 milestone that isn’t 100% bincompat with the 0.12.x final series.
    It should work fine, given that the breakage between the milestone and 0.12.0/1 is small and unlikely to be used by enumeration-circe, but that’s not guaranteed by MiMa.
    Lloyd
    @lloydmeta
    aah, thanks for pointing that out (circe-version lagging in enumeratum-circe and no mima guarantee). will cut + publish a new version.
    Ben Stewart
    @bastewart
    Thank you!
    Dermot Haughey
    @hderms
    guessing there's no way to have a 'catch all' enum
    like if none of the other ones match we get that one
    i'm guessing i should just write a matching function and not depend on withName
    or like withNameOption and then provide a default value
    it would be convenient if this existed so that circe would automagically do this for me
    Dermot Haughey
    @hderms
    seems undesirable actually so I think I answered my own question as making it easy to create encoders/decoders that throw away information seems contrary to the design of both libraries