Custom writer contexts

[TotalVerb]

#162 introduces JSON "contexts", which wrap around IO with additional information on how JSON is to be written. This concept is currently restricted to the concrete: a context only determines how JSON data is printed, not what JSON data is printed.

Other implementations of JSON, notably Scala's Play library, provide an additional layer of abstraction, where what JSON data is being printed can be encapsulated in a context. Such a "high-level" context would wrap around the "low-level" context.

Users of JSON will always demand configuration; see #96 and #108. But configuration is troublesome to maintain, and does not leverage the power of Julia's polymorphism.

Furthermore, the introduction of JSON.lower and JSON.show_json (as #162 will introduce) is great for packages to define serialization for their own types, but is liable to result in trouble if packages want to define serialization for others' types. Then, if two packages define conflicting serializations, things will break.

The proposal here is that we introduce an additional layer of abstraction, the Serialization{T<:IO} <: IO abstract type. (I'm not too fond of this name. Scala calls it Writes.) Then:

• The existing JSON serialization behaviour is associated with a StandardSerialization{T<:IO}(io::T) <: Serialization <: IO container.
• To define different serialization, one defines a different subtype of Serialization, and the show_json methods on it.

I think it's important to open this early, because it will affect the API of #162. It would be bad to suggest defining method

JSON.show_json(::IO, ::MyType)

because this will be far too broad, and interfere with situations where someone wants a restrictive serializer like in #108. Instead, it would be safer to define method

JSON.show_json(::JSON.StandardSerialization, ::MyType)

(hopefully with a shorter name).

[TotalVerb]

To be clear, I don't envision providing any such custom contexts—a library as fundamental as JSON needs to be lightweight and provide exactly what is necessary for the most common use case. The advantage of generalizations like #151 and #162 are that they do not actually introduce more code; in fact, the internal implementation of serialization is simplified by these generalizations.

This generalization will probably not introduce much code. All that's needed is an abstract Serialization and a concrete StandardSerialization type. The remaining code will only deal with the StandardSerialization type. In fact, in the long run, this should keep the amount of code in this package lower, because any features that people might like (such as a "restrictive mode") could be implemented and maintained in separate packages, instead of being necessarily added as a keyword argument in this one.

[TotalVerb]

#162 ended up containing a solution to this, so this can be closed now.