From d630d51b0a8d57452abfde837b298b2a5d9369b8 Mon Sep 17 00:00:00 2001 From: jhwgh1968 Date: Sat, 19 Aug 2023 17:45:34 -0500 Subject: [PATCH] Review comments --- src/functional/optics.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/functional/optics.md b/src/functional/optics.md index 31ca20d..3ecc80f 100644 --- a/src/functional/optics.md +++ b/src/functional/optics.md @@ -210,7 +210,7 @@ fn main() { 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 standard library already don't. Using this is a poor fit. This can easily be 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`, equivalent to the `Serde` class 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 - contains the logic to construct or destruct between the data type and the - format of the Serde data model. + trait, which are usually (but not always) is done through code generated by + a derive macro. This contains the logic to construct or destruct between the + data type and the format of the Serde data model. 1. The type implementing the `Deserializer` trait handles all details specific to the format, being "driven by" the `Visitor`.