All right. Now that you've engaged with our peer instruction and classroom discussion questions, let's go through and talk about what your students might say about this and how you can go over this with them. So our first question is really just to get students to walk through the steps of calling a constructor and passing values from where you call them into the parameters. All right. The correct answer is A, let's walk through that and then we'll walk through B. So this part is two instructions. In this, the first thing, we set the string x to salt, then we'll do the next instruction. So the next instruction calls the constructor and passes two parameters: first, the string literal pepper, and then the second thing is whatever the value is in the variable x. So since that has the value of salt, we could literally, when you're tracing code, you could copy that and say, "Okay, salt is the second parameter." Then we will actually execute calling that instruction. What that means is, as a student, I need to find the appropriate constructor that has the right number of parameters, of course we only have one here, not a problem there. The first parameter in the call pepper, is going to get copied up, and it's going to be assigned, literally that's like saying, salt equal quote, "pepper". So that's like assigning, take that value and stick it in that parameter named salt. Salt is going to be stuck into the parameter named pepper, that's confusing, I know. It's intentional that way. Then what's going to happen is that when we use the variable salt inside this method, we're going to be using whatever value is passed in as a parameter. So we're going to take the word pepper and store that in the instance variable s, and we're going to take the string salt and we're going to store that in the instance variable p. That alone, doing that backwards, is going to make a lot of students not choose it, but it's done intentionally and see the instructions up there. It says, "Which constructor will construct a SillyThing object with the value 'pepper' in s and 'salt' in p." They may be like, "Oh, that doesn't make sense." Well, a lot of times when they're testing these things in exam, they particularly give you things that don't make sense, even tricky as in this case, because the goal is don't do what seems to make sense. Show us that you can follow the exact execution that a computer makes. That's the goal of these questions. So what would happen with the other one, well, this is done all in one bit, it passed salt in for the first parameter and pepper and for the second parameter. So that's shown there. Then that will be signing salt, capital S, with the String salt into S, and capital P pepper into the String P which is something that might make more sense but that is not what we wanted. We wanted pepper in S and salt in P. So this one is weird enough then people or students will just be like [inaudible] when you say here's where the real learning outcomes. Parameters can be literals or variables and the first one in A, we use both a literal and a variable, sometimes students are like, no, no it has to just be a literal or something like that. By the way, it's the order of the parameters that matters not the names. Just because we named one "salt" and one "pepper" that doesn't matter. You have to match up the order into them and don't let them name throw you off, especially on tests. All right, next question. Is this signature more likely for an accessor or a mutator? We have to say likely because it didn't actually get the entire thing. The answer is an accessor. So remember that accessors are are also called getters. I personally prefer to call them getters but on the exam for AP they will call them accessors. In college we often call them both, accessors or getters, and mutators are setters. Accessor means get access or get, and mutator means change or set. So they really are the same words but sometimes getter and setter is easy. Oftentimes we even call our accessors and mutators get something or set something. Where the something is the instance variable name. So the key thing to remind students here is that when you're accessing something, you want to get something back, right? So that means that these accessors always have to have non void return types. I don't know exactly what the return type is. It depends on what the instance variable is that we're accessing, in this case hopefully it's an int because that's what we had, but it could be a string or it could be a double or it depends on the type of the instance variable, but we're going to get something because we're trying to get something. They generally don't have any parameters because I'm not changing. I don't need to send you some information Mr. Get Instance Variable Method in order for you to just give me that value back. So the key thing I like to remember here is the catch. We talked about that when we have the video but I've got my little baseball catch glove now. The accessors or getters need to be able to catch a value. So it's going to be returning a non-void type that you need to catch. We'll get back into that later. Next question. Same topic. It's just trying to wrap it all into one. So the key thing here is to get students to really focus on and call out the method header differences between mutators or setters, the first two columns, and accessors or getters in the second two columns. So if we apply what we just learned in the last slide, we can double-check that D is right. So accessors returns some value whatever the instance variable type is. Previously and I said a non void type. But this gets more specific and says look, the accessor should be returning an instance variable or a type that is the same type as the instance variable because that's what supposed to give you back; the value in the instance variable. They have no parameters. Now, mutators are the swap, right? Mutators, you want to change the value in that instance variable. So you need to send in a parameter which is what value you don't want to change it to. Mutator in general return void or nothing. That means that because you're not getting anything back, you just change it. Not needed to be known for this class, but sometimes you can have a Boolean return type for a mutator. In the case where you might not always make the change or if somebody gives you an invalid value and you don't want to change, you could return false to indicate that. Above and beyond what you need to know. However, that diagram is abstract, and was intended to be abstract. So one of the ways you might work students up to this is to show them, this is the code from the book that we covered on when we covered accessors and mutators and say put a box around all the acessor method calls and put a circle around all the mutator method calls. I'll give you a minute to look over it and see if you can figure out where you would put your boxes and circles. So our accessor once again, getters, getWidth. They return a value because we're printing it out, right? Yertele's width is. So they take no parameters and they'd better return a value because you're trying to say give me the value that's in that instance variable. Mutators over here in our circles. Those are setters, right? That's why I want to change the instance variable value. So I send a parameter in and there's no return value. I'm not catching something with an equal sign. I'm not catching something and printing it out. I'm just making the change. So it has a parameter and no return value. So back to our grid here. That should then be able to reinforce what we had here because we really want to pull out these differences. Mutators return nothing but they need a parameter. Accessors, they return something and they don't need a parameter. They're like mirrors, right? I intentionally have put this question after the previous one because it basically shows we had a particular application and then this is a more generalized explanation. So can they generalize from the specific to the general and then I also intentionally made it the last option because I wanted students to consider all the other ones. In this case, that's important. Number 3, 4, I don't remember which one to run. What happens when we run this code? Compile time error. We've got main there and we've got the main method is actually showing up first here int result through system.out.printIn result. Then foo is this method below there. Remember this is a static method. We talked about being able to have those. That's why it's public static in foo and I don't have to create any object and put that in object.foo is just static but still, that doesn't actually have anything to do with my error, the fact that it's a compile time error. So let's see. Here would be the actual stuff that would come out of Repl.it that you could use and I would encourage you for this particular example to go ahead and put it into Repl.it and run this with a student and use it to show them how they could figure out in running it this has compile time error before you show them how they could analyze it just like looking at it on paper and figure it out. So this is the error that would be printed if we tried to compile this code. The key thing to know about reading output from our compiler is you want to read it backwards. The last thing is probably where you want to start with. So we can see here it's a compiler error because it says "compiler exit status 1". So we can be sure of that. I'll also show you how you can figure it out. The next thing is, we'll go back another step and this is the actual error that came from the compiler. It says "main.java" and it tells us actually what line it's on, five. Then it gives us this error title or description that is sometimes helpful and sometimes not. In this case it was, "variable result might not have been initialized". It shows you line 5 and puts a little arrow to the variable result. Result might not have been initialized, that means result. In fact, it probably means doesn't actually have a value. We'll get back to that. Again, this is possibly the line with the error on it. Sometimes the compiler can't quite get that right, sometimes it's the line before the line, although oftentimes it might be the line afterwards but it's going to be close usually. But just know that sometimes the description is helpful, sometimes we'll have to learn how to interpret those crazy things and not always will this actually be the guaranteed line that has the problem. All right. Let's go back to the code that we're looking at. This was the code from the main. We declared the variable result but note we did not initialize it. That was that error down there that said may have been uninitialized, that means we didn't give it a value. Then we called foo. We'll go back and see foo is a method that was supposed to return an int, 10. But we didn't store that anywhere, like result did not get changed and then we tried to print the value of result and we attempted to use it. So this is where the compiler is complaining and saying you're trying to use the value of result that you have not initialized it and I don't know how to print something out that hasn't got a value. So the real problem here is that when we were making this call to the static method foo, even though look down below it says public static int foo and then it returns the number 10. We didn't catch that return, that value that was coming back from foo. I mean, it's not 100 percent certain that's exactly what we wanted to do, but you can kind of figure it out. So that was the mistake and the way it should have been done, the correct usage which would give us answer A is result equal foo. So we call the foo method and that returns the value 10 which we could write in there and then we'd store that into result and that would give us answer A. Answer B was sort of random and C was the difference between compile and runtime, we won't talk more about that. But in particular I will say that, now that we've gone in and started looking at some of our execution environments, this thing javac, that's the command, javac. It's Java compiler. That's what it means. That is going to be compiling your code. You can see, ignore all the stuff in the middle, the very last thing on that line is main.java. That's the name of the file that you are compiling. This is from a different example, but the one that actually compiled and could actually run, you'll see javac was the compile command, right? Then Java, that command Java with no "c", that's when you're actually running or interpreting the main bytecode. It's not assembly code. It's bytecode, that's a weird Java thing, but that's the part and so if you had any errors that came up after the word Java blah, blah, blah, those are going to be runtime errors.
