A:JSONW says: there needs to be a JSONW[A]
And then the compiler can do the work
It is a lot clearer
@sam
Oh. No. That’s the typeclass. Never mind. Duh. Uhmm. Just write your own
decompose[A: JSONW](value: A)?
Is the plan that json4s will have both forms going forward or is the type class one planned to obsolete
Formats someday?
There is also not much in the docs yet about the alternatives.
Imo teaching people about Formats is not the most responsible thing
The fundamental difference is that with Formats the typeclass instances are stored in a list, whereas a standard typeclass approach would declare only dependencies via implicit parameters
And I am working currently here https://github.com/dozed/json4s-drafts/
Here is for example a JSONW/JSONR instance for NonEmptyList (which is similar to Every): https://github.com/dozed/json4s-drafts/blob/master/src/test/scala/TupleMaps1.scala#L19
Where Result[A] has two possible cases,
Success(a) and Failure(errors)
sort of like sprayjson4s?
What is sjson style?
package services.json.formats
import services.schema.User
import User.Account
import services.schema.User
import spray.json._
object AccountFormat extends RootJsonFormat[Account] {
import DefaultJsonProtocol._
implicit val dateTimeFormat = DateTimeFormat
val format = jsonFormat5(Account.apply)
def read(value: JsValue) = format.read(value)
def write(account: Account) = format.write(account)
}
@eed3si9n There are the JSONW[A], JSONR[A] typeclasses in https://github.com/json4s/json4s/tree/3.4/scalaz
They had two modes
so it doesn't exist yet, but you guys are thinking about it?
Here is an example for the joda-time types https://github.com/dozed/json4s-drafts/blob/master/src/test/scala/JodaTimeExample.scala
It exists, officially in form of https://github.com/json4s/json4s/tree/3.4/scalaz, but it needs some polishing
anyfoo. thanks for the info!
Pretty sure I just spotted a bug while browsing the code trying to point out why using
json4s-native 3.3.x was an issue for another project: https://github.com/json4s/json4s/pull/339/files#r60582054
The fix is pretty trivial. I included code in my comment for it. Just didn’t feel like setting everything up, writing a failing spec and producing a PR. ;) Doesn’t impact me since I wouldn’t use the
alwaysEncodeUnicode option anyways. But if you do, I’m fairly confident the invalid-json-control-character bug is still present in that case.
