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?
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:
I'd appreciate any feedback, comment, whatever on this
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)
}
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.implicit def tryReader[T: ValueReader]: ValueReader[Try[T]]
that wraps the read in a Try and thus guarantee that it doesn’t blow up.implicit def eitherReader[L: ValueReader, R](implicit rReader: ValueReader[Try[R]])
where you can recover from that com.typesafe.config.ConfigException$WrongType
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.