Joni, be sure to take a look at jdegoes_issue_430.

I've defined Extractor and Decomposer traits, which can be bound together in a Serializer trait. The code uses the implicit typeclass pattern which makes for easy reading and writing (e.g. a.serialize.deserialize[A]).

This is part of the work I'm doing for issue 430: long-term, stable, robust JSON data storage (which is nearing completion).

I want to be sure we don't duplicate any effort.

Regards,

John

Hi,

I also tried to use typeclass pattern first but couldn't get it quite right. I agree that it would be the way to go but I got too many compilation issues (diverging implicits etc.) and eventually got frustrated :) I'm very interested to see if we could use that pattern which makes better use of the type system!

If you import DefaultSerialization._, you can do things like: 123.serialize.deserialize[Int], etc., for all basic Scala types. These serializers are used when building serializers for more complicated xschema data structures. So far it's working quite well.

I imagine we can incorporate this new style into lift-json. Reusing all the default serializers/deserializers to handle basic Scala types, then for case classes have something like:

implicit def GenericCaseClassDecomposer[T <: Product](implicit formats: Formats) = new Decomposer[T] {
override def decompose(tvalue: T): JValue = { lift json case class decomposition goes here }
}
implicit def GenericCaseClassExtractor[T <: Product](implicit m: Manifest[T], formats: Formats) = new Extractor[T] {
override def extract(jvalue: JValue): T = { lift json case class extraction goes here }
}

If user wants to provide custom serialization, they can then define a custom extractor/decomposer (of course it will have to be in scope at the point of serialization to override the above).

That's about the strategy I tried but failed. But I'm all for making an internal refactoring by using the scheme you have implemented, it looks wicked cool!

Here's my proposal.

- Add 430 stuff to master when it's ready.
- Then we try to unify the serialization schemes by building them on top of DefaultSerialization._
- If the above is successful let's deprecate the current way of configuring custom types (the stuff in Formats)

What do you think?

Sounds good to me. I will be wrapping up 430 next week.