Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 16 14:50
    scala-steward opened #88
  • Sep 16 01:37
    coveralls commented #86
  • Sep 15 21:05
    scala-steward opened #87
  • Sep 11 10:40
    scala-steward opened #86
  • Sep 11 06:19
    fmeeuw commented #82
  • Sep 10 16:44
    coveralls commented #85
  • Sep 10 16:32
    scala-steward opened #85
  • Sep 10 14:13
    kailuowang closed #78
  • Sep 10 14:13

    kailuowang on master

    Update sbt-sonatype to 2.6 (#83) (compare)

  • Sep 10 14:13
    kailuowang closed #83
  • Sep 10 14:13
    kailuowang closed #84
  • Sep 10 14:13

    kailuowang on master

    Update sbt to 1.3.0 (#84) (compare)

  • Sep 04 16:39
    coveralls commented #84
  • Sep 04 16:27
    scala-steward opened #84
  • Sep 04 04:09
    coveralls commented #83
  • Sep 04 03:58
    scala-steward opened #83
  • Aug 30 08:30
    fmeeuw opened #82
  • Aug 23 14:40

    kailuowang on master

    Update sbt-mima-plugin to 0.6.0… (compare)

  • Aug 23 14:40
    kailuowang closed #81
  • Aug 23 14:03
    coveralls commented #81
Shani Elharrar
@shanielh
Tell me what you think guys and I'll edit the commit message and create a pull request.
Joseph Price
@joprice
are you sure that does what you expect? simply calling arbitraryTypeValueReader should result in arbitraryTypeValueReader[Nothing]
capturing the arbitrary instance in parent value reader
Shani Elharrar
@shanielh
I guess that's fine. But actually I don't need the value, I only need to know it can be created :)
Joseph Price
@joprice
but doesn’t that run the macro twice?
Shani Elharrar
@shanielh
Changing my code to call the macro with the right type argument should work as well.
Joseph Price
@joprice
i haven’t measured this, but with a large adt, i’m sure it could be noticeable
Shani Elharrar
@shanielh
It will run the macro twice :(
But I couldn't find other way to do this.
Joseph Price
@joprice
hmm i guess my method could have some negative implications since ValueReader could be a different instance than the one created by calling arbitraryTypeValueReader
Kai(luo) Wang
@kailuowang
@shanielh sorry I am late, in the approach I suggested earlier, ParentValueReader does not implement/extend ValueReader, but it still does require self type to be ValueReader. So you marco still returns a ValueReader with ParentValueReader, but your two implicit defs returns two types that are parallel. So that when your as[A]() method looking for a ParentValueReader or your as[A](path: String) method looking for a ValueReader they won’t get ambiguous resolution? wouldn’t that work?
Shani Elharrar
@shanielh
I'll try that tomorrow
Kai(luo) Wang
@kailuowang
@joprice is there a way to tell valueClass from Macro? How easy to do this
iheartradio/ficus#29 ?
This message was deleted
Joseph Price
@joprice
not sure. id have to look at the reflection apis
looks like typeSymbol has a method isDerivedValueClass
Kai(luo) Wang
@kailuowang
@/all I apologize, when I released ficus 1.2.7 I didn’t realize that it’s binary incompatible with 1.2.6. I am releasing a 1.3.0 without code change.
Joseph Price
@joprice
we should use MIMA
Kai(luo) Wang
@kailuowang
agree
eyalfa
@eyalfa
hi guys
eyalfa
@eyalfa

I find myself in need for a Reader instance for Either[String,T] where T has a Reader instance, I actually started with Either[L,R] but then I realized the complexity behind it and 'retreated' to Either[String,T].
few questions:

  1. is there anything similar already in the library?
  2. will something like this be accepted as a pull-request?
  3. implementation guidelines; my initial approach is as follows:
    a. if path doesn't exist try reading it as T, this either fails or applies defaults
    b. otherwise attempt to read as string, this is not as simple as it sounds as Config.getString will (almost) always succeed...
    c. otherwise apply the provided reader for T

I'd appreciate any feedback, comment, whatever on this

Kai(luo) Wang
@kailuowang
@eyalfa hi sorry about the late response. I am not sure how useful a ValueReader[Either[String, T]] will be. A ValueReader for Either[L, R] would be more appealing. And you probably want to right biased.
Kai(luo) Wang
@kailuowang
I would imagine that the reader would be
implicit def eitherReader[L, R](implicitly rReader: ValueReader[Option[R]], lReader: ValueReader[L] )  = new ValueReader[Either[L, R]] {
   def read(cfg: Config, path:String): Either[L, R]  = 
        rReader.read(cfg, path).fold(Left(lReader.read(cfg, path))(Right)

}
eyalfa
@eyalfa
I'm alright with right biased
I've actually started with a generic either reader but it turned out to be quite complicated to get right.
I'm not sure if your proposal gets it right, option reader returns none in case of a missing path,if the path exist it applies the underlying reader which...might explode😎
eyalfa
@eyalfa
I think a better approach would use Try, even then it's very shady as we won't be able to tell if the exception is ficus related or not... In any case I'm personally not comfortable with code that relies on exceptions...
Thinking out loud, what if we had a second type class, CanRead[]
That indicates whether T can be read from the given Config object, the Either instance can require an instance of this type class,built-ins and macro generated ValueReader instances will implement the new trait as well.
Kai(luo) Wang
@kailuowang
@eyalfa you are right. The option approach wouldn’t work.
Kai(luo) Wang
@kailuowang
if the type isn’t right, you get a com.typesafe.config.ConfigException$WrongType, I don’t know if we have a way to have typesafe config validate the type instead of throwing an exception. My point is that we might have to use Try. If you have a CanRead type class it would probably use Try, unless we try to write our own string parser.
we can have a implicit def tryReader[T: ValueReader]: ValueReader[Try[T]] that wraps the read in a Try and thus guarantee that it doesn’t blow up.
Then you can have a implicit def eitherReader[L: ValueReader, R](implicit rReader: ValueReader[Try[R]]) where you can recover from that com.typesafe.config.ConfigException$WrongType
What do you think?
I think your main incentive for fixing the left type to String is to guarantee that it’s safe, but ficus API in general isn’t safe.
eyalfa
@eyalfa
I've actually started implementing the CanRead approach, so far I've handled all but the arbitrary. Started adding test minutes ago (after validating all existing tests pass). Will you be interested in looking at it? I can push to my fork
And yes,unfortunately I had to rely on exceptions, according to the javadocs, there are three kinds of exceptions to catch, one can only hope that the good fellows at type safe will ever be willing to improve their API...
eyalfa
@eyalfa
if you find this intersting:
Kai(luo) Wang
@kailuowang
I feel canRead API is cumbersome to use and has an extra runtime cost, it also introduce more code hence complexity. An auto derived ValueReader[Try[T]] would be more generally useful. People can do config.as[Try[Option[T]]] if they really want to be safe.
If you want to provide a way to differentiate good exception and bad, I guess an auto derived ValueReader[Either[Option[String], T]] is useful too. The left side could be the Some(string value) if the parsing fails due to type mismatch, or None if missing.
Kai(luo) Wang
@kailuowang
Then with ValueReader[Either[Option[String], T]] you should be able to write a ValueReader[Either[L, R]], but you need to be careful not let the two be ambiguous. (put them in a trait inheritance hierarchy)
eyalfa
@eyalfa
Hi,thanks for the review, while I really like the additional type class approach, I'm willing to admit its entire existence is to support the Either value reader.
Regarding the try based approach,there's no real need to require a value reader for option,the either value reader should require value readers for R and L, it will then internally wrap the R reader with a Try (that simply uses the already provided R reader), if it succeeds to parse the cfg into a Success(r) we return Right(r) otherwise we attempt the left reader.
eyalfa
@eyalfa
Notice that if either R or L is an Try, the read is guaranteed to succeed as these readers never fail. In case at least one of them is an option,we're gurantied not to crush in case of a missing path.
Kai(luo) Wang
@kailuowang
Sounds good.
eyalfa
@eyalfa
I'll find the time to sketch a pull request for this
eyalfa
@eyalfa
I did find the time :-) pushed #45
Bennett Andrews
@bennettandrews
Previous version of Ficus seem to be missing from Maven Central. I think they are being removed whenever you publish an update?
Kai(luo) Wang
@kailuowang
@bennettandrews we recently moved from bintray to Maven Central. so previous versions aren’t available there.
Mark Eibes
@i-am-the-slime
Hello.
Remko de Jong
@aggenebbisj
How do I load kebab case config into a case class with camel case values?