|
|
@ -210,7 +210,7 @@ fn main() {
|
|
|
|
|
|
|
|
|
|
|
|
That seems quite logical. However, there are two problems with this.
|
|
|
|
That seems quite logical. However, there are two problems with this.
|
|
|
|
|
|
|
|
|
|
|
|
First, `to_string` is to a very good way to explain "this is JSON." Every type
|
|
|
|
First, `to_string` does not indicate to API users, "this is JSON." Every type
|
|
|
|
would need to agree on a JSON representation, and many of the types in the Rust
|
|
|
|
would need to agree on a JSON representation, and many of the types in the Rust
|
|
|
|
standard library already don't. Using this is a poor fit. This can easily be
|
|
|
|
standard library already don't. Using this is a poor fit. This can easily be
|
|
|
|
resolved with our own trait.
|
|
|
|
resolved with our own trait.
|
|
|
@ -350,9 +350,9 @@ Thus we have the Serde API:
|
|
|
|
1. Each type to be serialized implements `Deserialize` or `Serialize`,
|
|
|
|
1. Each type to be serialized implements `Deserialize` or `Serialize`,
|
|
|
|
equivalent to the `Serde` class
|
|
|
|
equivalent to the `Serde` class
|
|
|
|
1. They get a type (well two, one for each direction) implementing the `Visitor`
|
|
|
|
1. They get a type (well two, one for each direction) implementing the `Visitor`
|
|
|
|
trait, which are usually (but not always) through macro-generated code. This
|
|
|
|
trait, which are usually (but not always) is done through code generated by
|
|
|
|
contains the logic to construct or destruct between the data type and the
|
|
|
|
a derive macro. This contains the logic to construct or destruct between the
|
|
|
|
format of the Serde data model.
|
|
|
|
data type and the format of the Serde data model.
|
|
|
|
1. The type implementing the `Deserializer` trait handles all details specific
|
|
|
|
1. The type implementing the `Deserializer` trait handles all details specific
|
|
|
|
to the format, being "driven by" the `Visitor`.
|
|
|
|
to the format, being "driven by" the `Visitor`.
|
|
|
|
|
|
|
|
|
|
|
|