NOT TO MERGE comments from nostarch on ch12 for review#563
NOT TO MERGE comments from nostarch on ch12 for review#563carols10cents wants to merge 1 commit into
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.
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.
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
grepfunction
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.
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.
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.
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.
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.
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...
| 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 |
| 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.
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.
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
| ``` | ||
|
|
||
| <!-- 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.
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"
| 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.
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.
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".
| <!-- 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.
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.
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.
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? --> |
| 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.
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.
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.
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.
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?--> |
| 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.
because collect creates a new collection, we want to just see if one thing exists
| 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.
people want more and more stuff here, idk
| <!-- 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.
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.