update original

Author: funkill

rustbook-en/nostarch/chapter18.md

@@ -39,10 +39,10 @@ keyword to decide which modules, types, functions, and methods in our code
 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
+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
 cache the calculated average for us. Listing 18-1 has the definition of the
-`AveragedCollection` struct:
+`AveragedCollection` struct.
 
 <Listing number="18-1" file-name="src/lib.rs" caption="An `AveragedCollection` struct that maintains a list of integers and the average of the items in the collection">
 
@@ -56,7 +56,7 @@ The struct is marked `pub` so that other code can use it, but the fields within
 the struct remain private. This is important in this case because we want to
 ensure that whenever a value is added or removed from the list, the average is
 also updated. We do this by implementing `add`, `remove`, and `average` methods
-on the struct, as shown in Listing 18-2:
+on the struct, as shown in Listing 18-2.
 
 <Listing number="18-2" file-name="src/lib.rs" caption="Implementations of the public methods `add`, `remove`, and `average` on `AveragedCollection`">
 
@@ -67,8 +67,8 @@ on the struct, as shown in Listing 18-2:
 </Listing>
 
 The public methods `add`, `remove`, and `average` are the only ways to access
-or modify data in an instance of `AveragedCollection`. When an item is added
-to `list` using the `add` method or removed using the `remove` method, the
+or modify data in an instance of `AveragedCollection`. When an item is added to
+`list` using the `add` method or removed using the `remove` method, the
 implementations of each call the private `update_average` method that handles
 updating the `average` field as well.
 
@@ -88,19 +88,19 @@ this wouldn’t necessarily be the case: `HashSet<i32>` and `Vec<i32>` 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 different parts of code enables encapsulation of implementation details.
+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
+different parts of code enables encapsulation of implementation details.
 
 ### Inheritance as a Type System and as Code Sharing
 
 _Inheritance_ is a mechanism whereby an object can inherit elements from
 another object’s definition, thus gaining the parent object’s data and behavior
 without you having to define them again.
 
-If a language must have inheritance to be object oriented, then Rust is not such
-a language. There is no way to define a struct that inherits the parent struct’s
-fields and method implementations without using a macro.
+If a language must have inheritance to be object oriented, then Rust is not
+such a language. There is no way to define a struct that inherits the parent
+struct’s fields and method implementations without using a macro.
 
 However, if you’re used to having inheritance in your programming toolbox, you
 can use other solutions in Rust, depending on your reason for reaching for
@@ -127,23 +127,23 @@ each other at runtime if they share certain characteristics.
 > ### Polymorphism
 >
 > To many people, polymorphism is synonymous with inheritance. But it’s
-> actually a more general concept that refers to code that can work with data
-> of multiple types. For inheritance, those types are generally subclasses.
+> actually a more general concept that refers to code that can work with data of
+> multiple types. For inheritance, those types are generally subclasses.
 >
 > Rust instead uses generics to abstract over different possible types and
 > trait bounds to impose constraints on what those types must provide. This is
 > sometimes called _bounded parametric polymorphism_.
 
-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
-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. 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 single inheritance
-(meaning a subclass can only inherit from one class), further restricting the
-flexibility of a program’s design.
+Rust has chosen a different set of tradeoffs by not offering inheritance.
+Inheritance is often at risk of sharing more code 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. 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 _single inheritance_ (meaning a
+subclass can only inherit from one class), further restricting the flexibility
+of a program’s design.
 
 For these reasons, Rust takes the different approach of using trait objects
-instead of inheritance. Let’s look at how trait objects enable polymorphism in
-Rust.
+instead of inheritance to enable polymorphism. Let’s look at how trait objects
+work.

rustbook-en/nostarch/docx/chapter18.docx

@@ -1,4 +1,8 @@
-## Using Trait Objects That Allow for Values of Different Types
+## Using Trait Objects to Abstract over Shared Behavior
+
+<!-- Old headings. Do not remove or links may break. -->
+
+<a id="using-trait-objects-that-allow-for-values-of-different-types"></a>
 
 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-9 where
@@ -19,13 +23,12 @@ some types for people to use, such as `Button` or `TextField`. In addition,
 instance, one programmer might add an `Image` and another might add a
 `SelectBox`.
 
-We won’t implement a full-fledged GUI library for this example but will show
-how the pieces would fit together. At the time of writing the library, we can’t
-know and define all the types other programmers might want to create. But we do
-know that `gui` needs to keep track of many values of different types, and it
-needs to call a `draw` method on each of these differently typed values. It
-doesn’t need to know exactly what will happen when we call the `draw` method,
-just that the value will have that method available for us to call.
+At the time of writing the library, we can’t know and define all the types
+other programmers might want to create. But we do know that `gui` needs to keep
+track of many values of different types, and it needs to call a `draw` method
+on each of these differently typed values. It doesn’t need to know exactly what
+will happen when we call the `draw` method, just that the value will have that
+method available for us to call.
 
 To do this in a language with inheritance, we might define a class named
 `Component` that has a method named `draw` on it. The other classes, such as
@@ -34,7 +37,7 @@ inherit the `draw` method. They could each override the `draw` method to define
 their custom behavior, but the framework could treat all of the types as if
 they were `Component` instances and call `draw` on them. But because Rust
 doesn’t have inheritance, we need another way to structure the `gui` library to
-allow users to extend it with new types.
+allow users to create new types compatible with the library.
 
 ### Defining a Trait for Common Behavior
 
@@ -56,12 +59,10 @@ 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
-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
-a trait object. Trait objects aren’t as generally useful as objects in other
-languages: their specific purpose is to allow abstraction across common
-behavior.
+concept is often labeled an object. Trait objects differ from objects in other
+languages in that we can’t add data to a trait object. Trait objects aren’t as
+generally useful as objects in other languages: their specific purpose is to
+allow abstraction across common behavior.
 
 Listing 18-3 shows how to define a trait named `Draw` with one method named
 `draw`.
@@ -77,8 +78,8 @@ Listing 18-3 shows how to define a trait named `Draw` with one method named
 This syntax should look familiar from our discussions on how to define traits
 in Chapter 10. Next comes some new syntax: Listing 18-4 defines a struct named
 `Screen` that holds a vector named `components`. This vector is of type
-`Box<dyn Draw>`, which is a trait object; it’s a stand-in for any type inside
-a `Box` that implements the `Draw` trait.
+`Box<dyn Draw>`, which is a trait object; it’s a stand-in for any type inside a
+`Box` that implements the `Draw` trait.
 
 <Listing number="18-4" file-name="src/lib.rs" caption="Definition of the `Screen` struct with a `components` field holding a vector of trait objects that implement the `Draw` trait">
 
@@ -103,8 +104,8 @@ This works differently from defining a struct that uses a generic type
 parameter with trait bounds. A generic type parameter can be substituted with
 only one concrete type at a time, whereas trait objects allow for multiple
 concrete types to fill in for the trait object at runtime. For example, we
-could have defined the `Screen` struct using a generic type and a trait bound
-as in Listing 18-6:
+could have defined the `Screen` struct using a generic type and a trait bound,
+as in Listing 18-6.
 
 <Listing number="18-6" file-name="src/lib.rs" caption="An alternate implementation of the `Screen` struct and its `run` method using generics and trait bounds">
 
@@ -130,7 +131,7 @@ Now we’ll add some types that implement the `Draw` trait. We’ll provide the
 `Button` type. Again, actually implementing a GUI library is beyond the scope
 of this book, so the `draw` method won’t have any useful implementation in its
 body. To imagine what the implementation might look like, a `Button` struct
-might have fields for `width`, `height`, and `label`, as shown in Listing 18-7:
+might have fields for `width`, `height`, and `label`, as shown in Listing 18-7.
 
 <Listing number="18-7" file-name="src/lib.rs" caption="A `Button` struct that implements the `Draw` trait">
 
@@ -166,7 +167,7 @@ Our library’s user can now write their `main` function to create a `Screen`
 instance. To the `Screen` instance, they can add a `SelectBox` and a `Button`
 by putting each in a `Box<T>` to become a trait object. They can then call the
 `run` method on the `Screen` instance, which will call `draw` on each of the
-components. Listing 18-9 shows this implementation:
+components. Listing 18-9 shows this implementation.
 
 <Listing number="18-9" file-name="src/main.rs" caption="Using trait objects to store values of different types that implement the same trait">
 
@@ -183,9 +184,9 @@ means it implements the `draw` method.
 
 This concept—of being concerned only with the messages a value responds to
 rather than the value’s concrete type—is similar to the concept of _duck
-typing_ in dynamically typed languages: if it walks like a duck and quacks
-like a duck, then it must be a duck! In the implementation of `run` on `Screen`
-in Listing 18-5, `run` doesn’t need to know what the concrete type of each
+typing_ in dynamically typed languages: if it walks like a duck and quacks like
+a duck, then it must be a duck! In the implementation of `run` on `Screen` in
+Listing 18-5, `run` doesn’t need to know what the concrete type of each
 component is. It doesn’t check whether a component is an instance of a `Button`
 or a `SelectBox`, it just calls the `draw` method on the component. By
 specifying `Box<dyn Draw>` as the type of the values in the `components`
@@ -225,25 +226,25 @@ Recall in [“Performance of Code Using
 Generics”][performance-of-code-using-generics]<!-- ignore --> in Chapter 10 our
 discussion on the monomorphization process performed on generics by the
 compiler: 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.
+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 know 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’s 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 method to
 call. This lookup incurs a runtime cost 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, and Rust has some rules, called
-_dyn compatibility_, about where you can and cannot use dynamic dispatch. Those
-rules are beyond the scope of this discussion, but  you can read more about them
-[in the reference][dyn-compatibility]. However, we did get extra flexibility in
-the code that we wrote in Listing 18-5 and were able to support in Listing 18-9,
-so it’s a trade-off to consider.
+code, which in turn prevents some optimizations, and Rust has some rules about
+where you can and cannot use dynamic dispatch, called _dyn compatibility_. Those
+rules are beyond the scope of this discussion, but you can read more about them
+[in the reference][dyn-compatibility]<!-- ignore -->. However, we did get extra
+flexibility in the code that we wrote in Listing 18-5 and were able to support
+in Listing 18-9, so it’s a trade-off to consider.
 
 [performance-of-code-using-generics]: ch10-01-syntax.html#performance-of-code-using-generics
 [dynamically-sized]: ch20-03-advanced-types.html#dynamically-sized-types-and-the-sized-trait