opened
ImLiar
username_0
This PR is my vision of `Decode` refactored implementation #562

I propose to introduce second type parameter `I` (for Input) for `Decode` trait:
```
trait Decode[I, A] {
  type ContentType <: String
  def apply(i: I): Try[A]
}
```

In this case we could iteratively move from `String` to `Buf` as @username_1 suggested in #511 and support multiple inputs via kind of "ad-hoc" polymorphism. I.e. it'll be super useful for implementation of Decode for `AsyncStream` (#520) where `String` or `Buf` couldn't be a case obviously. Also it will allow us to live some time with current JSON decoders which doesn't support `Buf` without dirty hacks (or doesn't support it at all :fearful:)

I'd be very glad of your advices, opinions and suggestions.
#562 Decode Refactoring
issue
created
vkostyukov
username_1
Thanks a lot @username_0! This looks pretty much similar to what I had in mind. Although, I still have a a couple concerns about using the same decoders for for both bodies and the rest of the HTTP entires (params, headers). Here is why:

1. Bodies is usually the most interesting part where different JSON/XML/whatever libraries kicks in
2. Params, headers, etc are all string-based and it should be easy to separate their concept from bodies 
3. I want to keep the API unchanged so when you say `param.as[Int]` it should use text decoder, but for `body.as[User]` - a JSON one. (is the later is broken right now?)

If don't want to repeat ourself, it should be pretty simple to implement `Decode.Aux[A, Text]` in terms of what we will have for params, headers, etc.

Anyways, I can only see all of this possible to do once our JSON decoders will know how to decode `Buf`. So there's should some major refactoring happen.
comment