Merge pull request #1266 from rust-lang/ch17-second-page-review

Changes made in 2nd page review of ch17

Author: carols10cents

second-edition/dictionary.txt

@@ -287,6 +287,7 @@ nocapture
 nomicon
 nondeterministic
 nonequality
+nongeneric
 NotFound
 null's
 OCaml
@@ -481,6 +482,7 @@ vers
 versa
 Versioning
 visualstudio
+Vlissides
 vtable
 wasn
 WeatherForecast

second-edition/src/SUMMARY.md

@@ -98,10 +98,10 @@
     - [Shared State](ch16-03-shared-state.md)
     - [Extensible Concurrency: `Sync` and `Send`](ch16-04-extensible-concurrency-sync-and-send.md)
 
-- [Is Rust an Object-Oriented Programming Language?](ch17-00-oop.md)
-    - [What Does Object-Oriented Mean?](ch17-01-what-is-oo.md)
-    - [Trait Objects for Using Values of Different Types](ch17-02-trait-objects.md)
-    - [Object-Oriented Design Pattern Implementations](ch17-03-oo-design-patterns.md)
+- [Object Oriented Programming Features of Rust](ch17-00-oop.md)
+    - [Characteristics of Object-Oriented Languages](ch17-01-what-is-oo.md)
+    - [Using Trait Objects that Allow for Values of Different Types](ch17-02-trait-objects.md)
+    - [Implementing an Object-Oriented Design Pattern](ch17-03-oo-design-patterns.md)
 
 ## Advanced Topics
 

second-edition/src/ch17-00-oop.md

@@ -1,13 +1,13 @@
-# Is Rust an Object-Oriented Programming Language?
+# Object Oriented Programming Features of Rust
 
 Object-oriented programming (OOP) is a way of modeling programs. Objects came
 from Simula in the 1960s. Those objects influenced Alan Kay’s programming
-architecture where objects pass messages to each other. He coined the term
-object-oriented programming in 1967 to describe this architecture. Many
+architecture in which objects pass messages to each other. He coined the term
+*object-oriented programming* in 1967 to describe this architecture. Many
 competing definitions describe what OOP is; some definitions would classify
-Rust as object oriented but other definitions would not. In this chapter, we’ll
-explore certain characteristics that are commonly considered object oriented
-and how those characteristics translate to idiomatic Rust. We’ll then show you
-how to implement an object-oriented design pattern in Rust and discuss the
-trade-offs of doing so versus implementing a solution using some of Rust’s
+Rust as object oriented, but other definitions would not. In this chapter,
+we’ll explore certain characteristics that are commonly considered object
+oriented and how those characteristics translate to idiomatic Rust. We’ll then
+show you how to implement an object-oriented design pattern in Rust and discuss
+the trade-offs of doing so versus implementing a solution using some of Rust’s
 strengths instead.

second-edition/src/ch17-01-what-is-oo.md

@@ -1,18 +1,19 @@
-## What Does Object Oriented Mean?
+## Characteristics of Object-Oriented Languages
 
 There is no consensus in the programming community about what features a
-language needs to be considered object oriented. Rust is influenced by many
-different programming paradigms, including OOP; for example, we explored the
-features that came from functional programming in Chapter 13. Arguably, OOP
-languages share certain common characteristics, namely objects, encapsulation,
-and inheritance. Let’s look at what each of those characteristics mean and
-whether Rust supports them.
+language must have to be considered object oriented. Rust is influenced by many
+programming paradigms, including OOP; for example, we explored the features
+that came from functional programming in Chapter 13. Arguably, OOP languages
+share certain common characteristics, namely objects, encapsulation, and
+inheritance. Let’s look at what each of those characteristics means and whether
+Rust supports it.
 
 ### Objects Contain Data and Behavior
 
-The book *Design Patterns: Elements of Reusable Object-Oriented Software*,
-colloquially referred to as *The Gang of Four book*, is a catalog of
-object-oriented design patterns. It defines OOP this way:
+The book *Design Patterns: Elements of Reusable Object-Oriented Software* by
+Enoch Gamma, Richard Helm, Ralph Johnson, and John Vlissides (Addison-Wesley
+Professional, 1994) colloquially referred to as *The Gang of Four* book, is a
+catalog of object-oriented design patterns. It defines OOP this way:
 
 > Object-oriented programs are made up of objects. An *object* packages both
 > data and the procedures that operate on that data. The procedures are
@@ -39,7 +40,7 @@ should be public, and by default everything else is private. For example, we
 can define a struct `AveragedCollection` that has a field containing a vector
 of `i32` values. The struct can also have a field that contains the average of
 the values in the vector, meaning the average doesn’t have to be computed
-on-demand whenever anyone needs it. In other words, `AveragedCollection` will
+on demand whenever anyone needs it. In other words, `AveragedCollection` will
 cache the calculated average for us. Listing 17-1 has the definition of the
 `AveragedCollection` struct:
 
@@ -112,14 +113,15 @@ the `average` field might become out of sync when the `list` changes. The
 `average` method returns the value in the `average` field, allowing external
 code to read the `average` but not modify it.
 
-Because we’ve encapsulated the implementation details of `AveragedCollection`,
-we can easily change aspects, such as the data structure, in the future. For
-instance, we could use a `HashSet` instead of a `Vec` for the `list` field. As
-long as the signatures of the `add`, `remove`, and `average` public methods
-stay the same, code using `AveragedCollection` wouldn’t need to change. If we
-made `list` public instead, this wouldn’t necessarily be the case: `HashSet`
-and `Vec` have different methods for adding and removing items, so the external
-code would likely have to change if it was modifying `list` directly.
+Because we’ve encapsulated the implementation details of the struct
+`AveragedCollection`, we can easily change aspects, such as the data structure,
+in the future. For instance, we could use a `HashSet` instead of a `Vec` for
+the `list` field. As long as the signatures of the `add`, `remove`, and
+`average` public methods stay the same, code using `AveragedCollection`
+wouldn’t need to change. If we made `list` public instead, this wouldn’t
+necessarily be the case: `HashSet` and `Vec` have different methods for adding
+and removing items, so the external code would likely have to change if it were
+modifying `list` directly.
 
 If encapsulation is a required aspect for a language to be considered object
 oriented, then Rust meets that requirement. The option to use `pub` or not for
@@ -132,9 +134,9 @@ object’s definition, thus gaining the parent object’s data and behavior with
 you having to define them again.
 
 If a language must have inheritance to be an object-oriented language, then
-Rust is not. There is no way to define a struct that inherits the parent
+Rust is not one. There is no way to define a struct that inherits the parent
 struct’s fields and method implementations. However, if you’re used to having
-inheritance in your programming toolbox, you can use other solutions in Rust
+inheritance in your programming toolbox, you can use other solutions in Rust,
 depending on your reason for reaching for inheritance in the first place.
 
 You choose inheritance for two main reasons. One is for reuse of code: you can
@@ -167,12 +169,13 @@ each other at runtime if they share certain characteristics.
 
 Inheritance has recently fallen out of favor as a programming design solution
 in many programming languages because it’s often at risk of sharing more code
-than needs be. Subclasses shouldn’t always share all characteristics of their
+than necessary. Subclasses shouldn’t always share all characteristics of their
 parent class but will do so with inheritance. This can make a program’s design
-less flexible and introduces the possibility of calling methods on subclasses
-that don’t make sense or that cause errors because the methods don’t apply to
-the subclass. Some languages will also only allow a subclass to inherit from
-one class, further restricting the flexibility of a program’s design.
+less flexible. It also introduces the possibility of calling methods on
+subclasses that don’t make sense or that cause errors because the methods don’t
+apply to the subclass. In addition, some languages will only allow a subclass
+to inherit from one class, further restricting the flexibility of a program’s
+design.
 
 For these reasons, Rust takes a different approach, using trait objects instead
 of inheritance. Let’s look at how trait objects enable polymorphism in Rust.

second-edition/src/ch17-02-trait-objects.md

@@ -1,8 +1,8 @@
 ## Using Trait Objects that Allow for Values of Different Types
 
-In Chapter 8, we mentioned that one limitation of vectors is that they can only
-store elements of one type. We created a workaround in Listing 8-10 where we
-defined a `SpreadsheetCell` enum that had variants to hold integers, floats,
+In Chapter 8, we mentioned that one limitation of vectors is that they can
+store elements of only one type. We created a workaround in Listing 8-10 where
+we defined a `SpreadsheetCell` enum that had variants to hold integers, floats,
 and text. This meant we could store different types of data in each cell and
 still have a vector that represented a row of cells. This is a perfectly good
 solution when our interchangeable items are a fixed set of types that we know
@@ -43,17 +43,17 @@ To implement the behavior we want `gui` to have, we’ll define a trait named
 takes a *trait object*. A trait object points to an instance of a type that
 implements the trait we specify. We create a trait object by specifying some
 sort of pointer, such as a `&` reference or a `Box<T>` smart pointer, and then
-specifying the relevant trait (we’ll talk about the reason trait objects must
-use a pointer in Chapter 19 in the section “Dynamically Sized Types & Sized”).
+specifying the relevant trait. (We’ll talk about the reason trait objects must
+use a pointer in Chapter 19 in the section “Dynamically Sized Types & Sized”.)
 We can use trait objects in place of a generic or concrete type. Wherever we
 use a trait object, Rust’s type system will ensure at compile time that any
 value used in that context will implement the trait object’s trait.
 Consequently, we don’t need to know all the possible types at compile time.
 
-We’ve mentioned that in Rust we refrain from calling structs and enums
+We’ve mentioned that in Rust, we refrain from calling structs and enums
 “objects” to distinguish them from other languages’ objects. In a struct or
 enum, the data in the struct fields and the behavior in `impl` blocks are
-separated, whereas in other languages the data and behavior combined into one
+separated, whereas in other languages, the data and behavior combined into one
 concept is often labeled an object. However, trait objects *are* more like
 objects in other languages in the sense that they combine data and behavior.
 But trait objects differ from traditional objects in that we can’t add data to
@@ -77,7 +77,7 @@ pub trait Draw {
 This syntax should look familiar from our discussions on how to define traits
 in Chapter 10. Next comes some new syntax: Listing 17-4 defines a struct named
 `Screen` that holds a vector named `components`. This vector is of type
-`Box<Draw>`, which is a trait object: it’s a stand-in for any type inside a
+`Box<Draw>`, which is a trait object; it’s a stand-in for any type inside a
 `Box` that implements the `Draw` trait.
 
 <span class="filename">Filename: src/lib.rs</span>
@@ -119,8 +119,8 @@ impl Screen {
 }
 ```
 
-<span class="caption">Listing 17-5: Implementing a `run` method on `Screen`
-that calls the `draw` method on each component</span>
+<span class="caption">Listing 17-5: A `run` method on `Screen` that calls the
+`draw` method on each component</span>
 
 This works differently than defining a struct that uses a generic type
 parameter with trait bounds. A generic type parameter can only be substituted
@@ -186,7 +186,7 @@ pub struct Button {
 
 impl Draw for Button {
     fn draw(&self) {
-        // Code to actually draw a button
+        // code to actually draw a button
     }
 }
 ```
@@ -198,9 +198,9 @@ The `width`, `height`, and `label` fields on `Button` will differ from the
 fields on other components, such as a `TextField` type, that might have those
 fields plus a `placeholder` field instead. Each of the types we want to draw on
 the screen will implement the `Draw` trait but will use different code in the
-`draw` method to define how to draw that particular type, like `Button` has
-here (without the actual GUI code that is beyond the scope of this chapter).
-`Button`, for instance, might have an additional `impl` block containing
+`draw` method to define how to draw that particular type, as `Button` has here
+(without the actual GUI code, which is beyond the scope of this chapter). The
+`Button` type, for instance, might have an additional `impl` block containing
 methods related to what happens when a user clicks the button. These kinds of
 methods won’t apply to types like `TextField`.
 
@@ -222,7 +222,7 @@ struct SelectBox {
 
 impl Draw for SelectBox {
     fn draw(&self) {
-        // Code to actually draw a select box
+        // code to actually draw a select box
     }
 }
 ```
@@ -284,10 +284,10 @@ It doesn’t check whether a component is an instance of a `Button` or a
 `Screen` to need values that we can call the `draw` method on.
 
 The advantage of using trait objects and Rust’s type system to write code
-similar to code using duck typing is that we never have to check that a value
-implements a particular method at runtime or worry about getting errors if a
-value doesn’t implement a method, but we call it anyway. Rust won’t compile our
-code if the values don’t implement the traits that the trait objects need.
+similar to code using duck typing is that we never have to check whether a
+value implements a particular method at runtime or worry about getting errors
+if a value doesn’t implement a method but we call it anyway. Rust won’t compile
+our code if the values don’t implement the traits that the trait objects need.
 
 For example, Listing 17-10 shows what happens if we try to create a `Screen`
 with a `String` as a component:
@@ -326,36 +326,36 @@ error[E0277]: the trait bound `std::string::String: gui::Draw` is not satisfied
 ```
 
 This error lets us know that either we’re passing something to `Screen` we
-didn’t mean to pass and we should pass a different type, or we should implement
+didn’t mean to pass and we should pass a different type or we should implement
 `Draw` on `String` so that `Screen` is able to call `draw` on it.
 
 ### Trait Objects Perform Dynamic Dispatch
 
 Recall in the “Performance of Code Using Generics” section in Chapter 10 our
 discussion on the monomorphization process performed by the compiler when we
-use trait bounds on generics: the compiler generates non-generic
-implementations of functions and methods for each concrete type that we use in
-place of a generic type parameter. The code that results from monomorphization
-is doing *static dispatch*, which is when the compiler knows what method you’re
-calling at compile time. This is opposed to *dynamic dispatch*, which is when
-the compiler can’t tell at compile time which method you’re calling. In dynamic
+use trait bounds on generics: the compiler generates nongeneric implementations
+of functions and methods for each concrete type that we use in place of a
+generic type parameter. The code that results from monomorphization is doing
+*static dispatch*, which is when the compiler knows what method you’re calling
+at compile time. This is opposed to *dynamic dispatch*, which is when the
+compiler can’t tell at compile time which method you’re calling. In dynamic
 dispatch cases, the compiler emits code that at runtime will figure out which
 method to call.
 
 When we use trait objects, Rust must use dynamic dispatch. The compiler doesn’t
 know all the types that might be used with the code that is using trait
 objects, so it doesn’t know which method implemented on which type to call.
 Instead, at runtime, Rust uses the pointers inside the trait object to know
-which specific method to call. There is a runtime cost when this lookup happens
-that doesn’t occur with static dispatch. Dynamic dispatch also prevents the
-compiler from choosing to inline a method’s code, which in turn prevents some
+which method to call. There is a runtime cost when this lookup happens that
+doesn’t occur with static dispatch. Dynamic dispatch also prevents the compiler
+from choosing to inline a method’s code, which in turn prevents some
 optimizations. However, we did get extra flexibility in the code that we wrote
 in Listing 17-5 and were able to support in Listing 17-9, so it’s a trade-off
 to consider.
 
 ### Object Safety Is Required for Trait Objects
 
-You can only make *object safe* traits into trait objects. Some complex rules
+You can only make *object-safe* traits into trait objects. Some complex rules
 govern all the properties that make a trait object safe, but in practice, only
 two rules are relevant. A trait is object safe if all the methods defined in
 the trait have the following properties:
@@ -391,7 +391,7 @@ of `Vec`. The signature of `clone` needs to know what type will stand in for
 `Self`, because that’s the return type.
 
 The compiler will indicate when you’re trying to do something that violates the
-rules of object safety in regards to trait objects. For example, let’s say we
+rules of object safety in regard to trait objects. For example, let’s say we
 tried to implement the `Screen` struct in Listing 17-4 to hold types that
 implement the `Clone` trait instead of the `Draw` trait, like this: