-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Custom writer contexts #165
Comments
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 |
#162 ended up containing a solution to this, so this can be closed now. |
#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
andJSON.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 itWrites
.) Then:StandardSerialization{T<:IO}(io::T) <: Serialization <: IO
container.Serialization
, and theshow_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
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
(hopefully with a shorter name).
The text was updated successfully, but these errors were encountered: