17-3 rationale for using Option for State is still unclear
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 18.3k
- Forks
- 4.1k
- Avg merge
- 14m
- Merged PRs (30d)
- 1
Description
-
I have searched open and closed issues and pull requests for duplicates, using these search terms:
- self.state.request_review
-
I have checked the latest
mainbranch to see if this has already been fixed, in this file:
URL to the section(s) of the book with this problem:
https://doc.rust-lang.org/book/ch17-03-oo-design-patterns.html#requesting-a-review-of-the-post-changes-its-state
Description of the problem:
The following sentence is still very confusing:
We need to set state to None temporarily rather than setting it directly with code like self.state = self.state.request_review(); to get ownership of the state value. This ensures Post can’t use the old state value after we’ve transformed it into a new state.
First, "We need" implies that self.state = self.state.request_review() gives the incorrect result. However, it actually gives the correct result; from https://github.com/rust-lang/book/issues/837, the intent here is to make the code less error-prone in case that line is later commented out.
Additionally. "This ensures Post can’t use the old state value after we’ve transformed it into a new state." seems misleading too. Post already cannot use the old state value, since the self parameter is moved in request_review(self: Box<Self>). This would only "ensure" if we for some reason changed the self parameter to borrow.
Suggested fix:
Please add a paragraph making it clear that the usage of Option is solely to make the code less error-prone in the face of future refactorings, and not explicitly needed for correctness.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read src/ch17-03-oo-design-patterns.md at the section on requesting a review of the post changes its state, along with the referenced discussion in issue 837. Revise the explanation so it distinguishes correctness from protection against future refactoring, then verify the rendered book section clearly reflects that rationale.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 1/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 45/100