I can't see how to enforce this and have the
Decoder's map method return the correct type without using F-bound types, which is noisy and seems to have become something of a code smell
You can make things a little cleaner by adding a type parameter rather than using subtyping to distinguish "formats":
trait Decoder[C, A] {
def map[B](f: A => B): Decoder[C, A]
// ...
}The C type parameter could be completely unconstrained, could be a type-level string representing a content type, etc.
I also like the idea of not having to extend
Decoder for each new decoded type, everything could just be a Decoder[E, D, F, C], where E is the encoded type, D the decoded type, F the failure type (the left part of an Either like structure) and C solely used for specialisation
I must confess that I'm a bit more fuzzy on the type level string, though, and will need to read up on that. Is it simply a singleton type, or is there more to it than that?
The idea is that you could enumerate all possible formats that could be used as the C type with something like this:
class ContentType(val contentType: String)
case object ApplicationJson extends ContentType("application/json")
case object PlainText extends ContentType("text/plain")
...But that's hugely verbose and not extensible in the right ways.
These are essentially phantom types—we do have instances, but really we're just using them as markers to distinguish decoding formats.
The Scala compiler has singleton types for every string literal—there's just no way to refer to them without something like Shapeless or a custom macro. That means that instead of enumerating all of our content types (or formats, or whatever we want to call them), we can just use the string literal singleton types.
(Where
"application/json".type is shorthand for shapeless.Witness.`"application/json"`.T or whatever technique you're using to refer to the type-level string.)
I mean, you'd presumably type alias things -
type CsvDecoder[A] = Decoder[CsvTag, A] and never even really expose CsvTag
well, you'd expose it, but callers would never need to know it exists
do you see the explicit content type as some sort of type-level documentation?
oh, I see
it probably is not a good idea, but it's true that some decoders are going to have lots of duplicated code. I have a CSV library, for instance, that defines a decoder for most primitive types, and another XPath one that defines almost exactly the same ones
the only difference is in the failure type and, if we assume content types at the type level, the content-type
One downside I see to the content-type approach is that it might not be specific enough. What exactly is an XML decoder? is it something that knows how to decode XML attributes, which surely is not quite the same thing as decoding results of XPath expressions, or an XML document itself?
About your last question: the rule of thumb would be "if you'd serve some content using this content type, this decoder can decode it to type
X".
that's part of the beauty of your idea, really: a
Decoder instance for a give content type would have the same type, regardless of the library that implements it
but you might find yourself having part of your JSON document extracted by circe instances and others by Argonaut ones, if you have weird dependencies, and I feel this might not be desirable
…they could do that with
import io.circe.generic.auto._ or by defining an Argonaut instance, but that doesn't (and shouldn't have to) matter to my code.
ok. I need to play with this a bit, get my head around the concept, but I appreciate you taking the time to discuss this. It certainly not something I considered - nor something I could have considered, really, it's the first time the idea of using phantom types to specialise type class instances even registered as something that one could do
in all your example, you only have 2 type parameters - content-type and decoded type. Does that mean that you're expecting all
Decoders to work from in-memory strings, or is that just a shortcut?
circe's codec type will also have an additional configuration type parameter very soon (something we need to help guide generic derivation, among other things—I've got a blog post about it here).
let's say I'm scrapping some website and am interested in two different parts of a given page. I'd rather parse the thing as a
Node once and evaluate my expressions on this
if that makes sense
but they would need to become generic over the input type if they were to use the
Decoder type class you have in mind, right?
laws in particular are becoming quite a bit clearer