rereading im not sure what your qeustion is, but if you're wondering, that will compile and work correctly. In fact, its a common style.
The Big Programming Thread - Page 766
Forum Index > General Forum |
Thread Rules 1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution. 2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20) 3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible. 4. Use [code] tags to format code blocks. | ||
solidbebe
Netherlands4921 Posts
rereading im not sure what your qeustion is, but if you're wondering, that will compile and work correctly. In fact, its a common style. | ||
Blitzkrieg0
United States13132 Posts
On September 24 2016 02:21 travis wrote: What happens if my class has a variable: class { int variable; //and then the constructor takes a parameter with the same variable name and does this: class(int variable){ this.variable = variable; It sets the field in the class to value of the parameter passed to the method. You're calling this.variable to specify that you want the variable in a different scope than the method. The variable without this declaration is assumed to be in the method scope. ** I'll try to go a bit deeper and explain this better: public class Box { So given the previous bit of code, I have a class with a couple fields. In the constructor for my box object, I have a variable called id. There is not an id variable in the scope of the constructor so its assumed that I am referencing the id field of the object. In the setId method you'll notice that I have a parameter called id so I call this.id to specify to the compiler that I want the id variable in this objects scope instead of the method. | ||
Deleted User 3420
24492 Posts
when I do this.variable = variable; how does it know that I am talking about the parameter that was passed, or if I was talking about the uninitialized variable. I guess the answer is, "it just does" ? (so mainly I was making sure this does in fact work) | ||
Acrofales
Spain17824 Posts
On September 24 2016 02:34 travis wrote: I guess my question was kind of like when I do this.variable = variable; how does it know that I am talking about the parameter that was passed, or if I was talking about the uninitialized variable. I guess the answer is, "it just does" ? (so mainly I was making sure this does in fact work) It's not "it just does". It's about scope, as the answer explained. If you don't understand scopes, it's something you have to read up on. It's a very important part of almost all programming languages. | ||
Deleted User 3420
24492 Posts
I understand scope. I don't think my question is about scope if this was my program public class myclass { int number = 7; int number2; myclass(int number){ this.number2 = number; } then what happens | ||
Blitzkrieg0
United States13132 Posts
| ||
spinesheath
Germany8679 Posts
On September 24 2016 02:34 travis wrote: I guess my question was kind of like when I do this.variable = variable; how does it know that I am talking about the parameter that was passed, or if I was talking about the uninitialized variable. I guess the answer is, "it just does" ? (so mainly I was making sure this does in fact work) The field "variable" is in object scope, the constructor parameter "variable" is in method scope. Relative to each other, the field is in the outer scope and the parameter is in the inner scope (think Matryoshka doll). Variables with the same name in an inner scope "hide" or "shadow" variables in outer scopes. So whenever you write just "variable", you will use the one closest to your current scope. That's the parameter if you're inside the constructor. If you write "this.variable", it will always look for a variable at object scope. This allows you to access the otherwise hidden field. Remember that part recently where we couldn't find the reason for the null reference exception and then it turned out you just had to delete the type declaration "ArrayList<FoundTerm>"? That was exactly because with the type in front of the variable name you were declaring a new variable that hid one with the same name at object scope that you actually wanted to use instead. I'm not a big fan of using hiding like that in constructors because it can introduce hard to spot errors. In some languages it is common practice to prefix variables at object scope, for example with an "m" (often in C++) or an underscore (C#). That way you can still use the plain name for stuff at the method scope, most commonly in the constructor. EDIT: I wrote "class scope" before when I think it should actually be "object scope". Class scope should be static stuff only, while object scope is variables that are unique to each instance of a class. | ||
Acrofales
Spain17824 Posts
On September 24 2016 02:48 travis wrote: ok, I didn't answer the question in a way that really gets to the root of what I am wondering about, since I used the this keyword I understand scope. I don't think my question is about scope if this was my program public class myclass { int number = 7; int number2; myclass(int number){ this.number2 = number; } then what happens You get scolded for using horrid syntax, and told to use proper builder patterns instead. But it's about the order of variable assignment. It works as you'd expect. Upon calling the constructor, the first act is to call the super constructor. If you don't do this explicitly, it is done implicitly. This creates the object you are constructing, and initializes your global variables. After that it runs your constructor, and changes the value of variable "number2" to the parameter you passed. | ||
Deleted User 3420
24492 Posts
and that the lesson is that when variables have the same name, the more local variable takes precedence? | ||
Manit0u
Poland17182 Posts
On September 24 2016 03:03 travis wrote: Okay thanks all, so I guess it is a scope issue and that the lesson is that when variables have the same name, the more local variable takes precedence? A common mistake I see people make (example is from PHP):
Also, I don't think you should be declaring classes within classes... | ||
Blisse
Canada3710 Posts
On September 24 2016 03:03 travis wrote: Okay thanks all, so I guess it is a scope issue and that the lesson is that when variables have the same name, the more local variable takes precedence? I would say it depends on the language? I wouldn't say "more local" though, I think "closest in scope" is clearer, but maybe "more local" is easier to understand. See if these make sense to you. http://stackoverflow.com/questions/2804880/in-c-what-is-the-scope-resolution-order-of-precedence-for-shadowed-variab Behind the scenes, a compiler (preprocessor? one of those steps) (usually?) mangles the name of (all?) variables so it doesn't actually see your variable name. They then use the language rules to deduce which ones to call. http://stackoverflow.com/questions/22067562/how-c-handles-the-same-variable-name-along-different-scopes | ||
Acrofales
Spain17824 Posts
On September 24 2016 04:51 Manit0u wrote: A common mistake I see people make (example is from PHP):
Also, I don't think you should be declaring classes within classes... Not necessarily wrong to declare nested classes. I agree that it's fairly advanced, though, and as a beginner you are better off not doing that. | ||
RoomOfMush
1296 Posts
On September 24 2016 02:54 spinesheath wrote: I'm not a big fan of using hiding like that in constructors because it can introduce hard to spot errors. In some languages it is common practice to prefix variables at object scope, for example with an "m" (often in C++) or an underscore (C#). That way you can still use the plain name for stuff at the method scope, most commonly in the constructor. Although I am not a big fan of naming parameters the same as fields either, it must be noted that todays IDE's are more than capable of detecting these kinds of bugs and generating a warning. I know for a fact that Eclipse will warn you if you assign a parameter to itself. | ||
Birdie
New Zealand4438 Posts
On September 24 2016 08:07 RoomOfMush wrote: Although I am not a big fan of naming parameters equal to fields either, it must be noted that todays IDE's are more than capable of detecting these kinds of bugs and generating a warning. I know for a fact that Eclipse will warn you if you assign a parameter to itself. Correct me if I'm wrong but I think the issue is more the readability of the code, not the compilability. If it's not immediately clear which of two variables is being referenced, then time is wasted on the main work of coding (which is reading). | ||
RoomOfMush
1296 Posts
On September 24 2016 08:08 Birdie wrote: Correct me if I'm wrong but I think the issue is more the readability of the code, not the compilability. If it's not immediately clear which of two variables is being referenced, then time is wasted on the main work of coding (which is reading). Thats a matter of personal taste, but spinesheath was explicitly talking about "hard to spot errors" and I assume he ment missing the "this" operator and assigning a parameter to itself. But todays IDE's also have something for your particular problem: Syntax highlighting. Just tell your IDE to highlight fields in a different color to parameters and it will become quite obvious which one is being used. | ||
spinesheath
Germany8679 Posts
Syntax highlighting is not part of your codebase. So if you ever work with others, you better not rely on that. | ||
Acrofales
Spain17824 Posts
On September 24 2016 17:03 spinesheath wrote: You can just as well read from or write to a variable in inner scope thinking you're working with a field. That doesn't have to involve any self assignment. Obviously IDEs can show a warning for that too, but if you use shadowing in your constructors regularly, then all your constructors will be littered with these warnings. So I suppose that most people who do that have the warning disabled. Syntax highlighting is not part of your codebase. So if you ever work with others, you better not rely on that. Huh? That's not when it shows a warning.
| ||
spinesheath
Germany8679 Posts
| ||
Acrofales
Spain17824 Posts
On September 24 2016 18:03 spinesheath wrote:
Yeah, ok. That's pretty bad. Anybody using shadowing like that is asking for it, though ![]() I mean, I'm not a fan of shadowing in general and never use it, except in the constructor to initialize fields. And that goes at the bottom of the constructor, so any operations you do before just setting the field aren't affected b the potential bugs you describe. | ||
Prillan
Sweden350 Posts
On September 24 2016 18:03 spinesheath wrote:
One reason why I like the explicit self in python.
| ||
| ||