-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NOT TO MERGE comments from nostarch on ch12 for review #563
Conversation
We're calling our version 'greprs'. | ||
|
||
<!-- Unless I'm misunderstanding something, it seems like we start calling it | ||
merely "greps" at the end of the project, maybe something to look out for --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I checked (with grep
! ha!) and we don't say greps
anywhere. Based on her comment later, I think she means just grep
, not greprs
, and she's confused because we name the function just grep
. Maybe we should call that function "search" or something.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the first bullet point here may not have made it into RFC 1574, but perhaps you could follow that here to help differentiate when you're talking about the function rather than the entire program?
All the lines like:
the
grep
function
Could be something like:
the
grep()
function
Or possibly just:
grep()
Where appropriate.
Or maybe that doesn't match the rest of the book!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like that wouldn't match the rest of the book!
And I finished reading your post, the suggestion of changing the function name is much better!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seconded, changing the name is probably better
<!-- We might need a more descriptive title, something that captures the new | ||
elements we're introducing -- are we going to cover things like environment | ||
variables more in later chapters, or is this the only place we explain how to | ||
use them? --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Keep reading... later she actually suggests cutting the env var and stderr sections, so come back to this comment once we decide what's going to be in or out of this chapter.
- Running tests (Chapter 11) | ||
|
||
We'll also briefly introduce closures, iterators, and trait objects, which | ||
Chapters XX, YY, and ZZ respectively will cover in detail. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will fill these in when I make edits
<!--Below -- I'm not clear what we need the args function for, yet, can you set | ||
it out more concretely? Otherwise, will it make more sense in context of the | ||
code later? Is this function needed to allow our function to accept arguments, | ||
is that was "args" is for? --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe show an example invocation of the command with arguments that we're going for.... that's the only thing I can think of since we explain that grep takes 2 command line arguments for the string and the file to search in the intro...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah
understand much about how they work in order to use them. We only need to | ||
understand two things: | ||
arguments that were given to our program. We haven't discussed iterators yet, | ||
and we'll cover them fully in Chapter 16, but for our purposes now we only need |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
13
to implement `grep`: | ||
Great, our test fails, exactly as we expected. Let's get the test to pass! | ||
|
||
### Testing to Succeed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
making the test pass
We use a `for` loop along with the `lines` method to get each line in turn. | ||
|
||
<!-- so what does `lines` do on its own, if we need to use it in a for loop to | ||
work? --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will add that it returns an iterator, reference some of the places where we've used a for
loop before here to go through each item in a list
@@ -1217,22 +1345,38 @@ To tell your name the livelong day | |||
To an admiring bog! | |||
``` | |||
|
|||
<!-- Maybe this second one should be a more specific example, a whole word | |||
match, like "nobody"? These results are not immediately clear --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'll break this out more, say "let's try a search for nobody
that should return exactly one line, ok, let's try something that should match multiple lines, ok now something that matches substrings of words"
Excellent! We've built our own version of a classic tool, and learned a lot | ||
about how to structure applications. We've also learned a bit about file input | ||
and output, lifetimes, testing, and command line parsing. | ||
|
||
<!-- If we'er going into environment variable more thoroughly in a later | ||
chapter, I might suggest we cut this next bit --- I'm not sure it will be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
idk how i feel about this. i dont want to talk about it later, this is just like... useful formulas
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to add a little thing that says to move on to chapter 13 if you want, but that we're going to briefly demonstrate env vars and stderr before calling this "done".
|
||
The `std::env` module contains many more useful features for dealing with | ||
environment variables; check out its documentation to see what's available. | ||
|
||
<!-- And this section, too, might be too much. We might be wearing the reader | ||
out at this point --> | ||
|
||
## Write to `stderr` Instead of `stdout` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
given that RFC for adding errln!
or whatever is coming, maybe cutting this would be for the best...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
until it lands though, knowing how to do this is important, and it won't change the section that much.
We're calling our version 'greprs'. | ||
|
||
<!-- Unless I'm misunderstanding something, it seems like we start calling it | ||
merely "greps" at the end of the project, maybe something to look out for --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seconded, changing the name is probably better
<!--Below -- I'm not clear what we need the args function for, yet, can you set | ||
it out more concretely? Otherwise, will it make more sense in context of the | ||
code later? Is this function needed to allow our function to accept arguments, | ||
is that was "args" is for? --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah
a lone `args`. Also, if we end up using more than one function in `std::env`, | ||
we only need a single `use`. | ||
First, we bring the `std::env` module into scope with a `use` statement so that | ||
we can use its `args` function. Notice we have two environments here: the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also, we've already talked about this already, right?
so we put a reference to the first argument in the variable `search`. The | ||
second argument will be the filename, so we put a reference to the second | ||
argument in the variable `filename`. Let's try running this program again: | ||
Remember, the program's name takes up the first argument at `args[0]`, so we |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is something we just mentioned above now, so repeating it feels like too much, idk
the chapter.--> | ||
|
||
<!-- This might be more distracting than useful at this point, ok to cut this | ||
bit? I added a smaller summary line above --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, idk. i feel...whatever
<!-- Will add ghosting and wingdings in libreoffice /Carol --> | ||
|
||
<!-- what does returning a Result rather than a Config do? --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we have a whole chapter on this :(
the unit type, `()`, and we keep that as the value returned in the `Ok` case. | ||
|
||
<!-- is just the `Box` bit the trait object, or the whole `Box<Error>` | ||
syntax?--> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the whole thing
of the environment variable and its value. | ||
|
||
<!-- why do we use a loop rather than collect? what benefit does it have, and | ||
why use it here but not previously?--> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
because collect creates a new collection, we want to just see if one thing exists
|
||
The `std::env` module contains many more useful features for dealing with | ||
environment variables; check out its documentation to see what's available. | ||
|
||
<!-- And this section, too, might be too much. We might be wearing the reader | ||
out at this point --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
people want more and more stuff here, idk
|
||
The `std::env` module contains many more useful features for dealing with | ||
environment variables; check out its documentation to see what's available. | ||
|
||
<!-- And this section, too, might be too much. We might be wearing the reader | ||
out at this point --> | ||
|
||
## Write to `stderr` Instead of `stdout` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
until it lands though, knowing how to do this is important, and it won't change the section that much.
Replaced by #576 |
No description provided.