capturing the arbitrary instance in parent value reader
But I couldn't find other way to do this.
@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?
This message was deleted
looks like typeSymbol has a method isDerivedValueClass
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:
- is there anything similar already in the library?
- will something like this be accepted as a pull-request?
- 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
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)
}
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😎
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.
if the type isn’t right, you get a
we can have a
Then you can have a
What do you think?
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$WrongTypeWhat 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.
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...
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.
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.
