   C# Class Question
  I got a question about C# classes.This isn't problem-related, I just want to better understand something.Scenerio:  I have a field, lets call it string name, I declare it at the top of the class.  Now, in a overloaded constructor I also declare string name as a parameter.  I'm just curous:  Why don't these two initializations conflict with each other?class clsCool{//fieldstring name;//overloaded constructorpublic clsCool(string name)  <-- initializing string with same name as a field??<-- insert code here and it refers to the parameter -->//constructorpublic clsCool()<-- when I insert code here, it refers to the field string -->}Can anyone explain this behavior to me, because it doesn't fit in my concept with scopes.   
  It's all to do with scope and how the compiler looks for the definition of symbols. When evaluating the symbol 'name', the compiler starts from the innermost scope, in your constructor example that would be the function level and a symbol is found as a parameter. If no matching symbol is found, such as the clsCool function it moves up the scope hierarchy. In this case, the next is class scope and there is a symbol with the same name. The tricky bit is refering to the class 'name' in a function with a parameter called 'name', here you will need to use scope resolution to tell the compiler which symbol to use.Skizz   ;Quote:Original post by SkizzIt's all to do with scope and how the compiler looks for the definition of symbols. When evaluating the symbol 'name', the compiler starts from the innermost scope, in your constructor example that would be the function level and a symbol is found as a parameter. If no matching symbol is found, such as the clsCool function it moves up the scope hierarchy. In this case, the next is class scope and there is a symbol with the same name. The tricky bit is refering to the class 'name' in a function with a parameter called 'name', here you will need to use scope resolution to tell the compiler which symbol to use.SkizzWow that makes perfect sense, thanks for the fast reply, mate.;  Keep in mind though that while the compiler may not see a problem, it can certainly become confusing to the programmer. 6 months from now if you're adjusting the code, you may or may not remember that there is more than one Name variable accessible from that function.   ;Quote:Original post by ItsDanKeep in mind though that while the compiler may not see a problem, it can certainly become confusing to the programmer. 6 months from now if you're adjusting the code, you may or may not remember that there is more than one Name variable accessible from that function.Very good point Dan, and thanks for the tip.I certainly won't be making that mistake... just wanted to know exactly what was going on behind the scenes with the compiler.   ;  For the record (which is probably already obvious to you) this.name inside the constructor will refer to the class field member, allowing you to do this.name = name.I tend to restrict this sort of thing to constructors, and C#3 adds object initialisers which will help get rid of it from there too.   