Dual nature of myClass in C#

Question

myclass is working as string as well as myClass in below example.

I know everyone will say this is not a good habit to use something like in below example.

CODE:

class myClass
{
    public static void Main(string[] args)
    {   
        string @myClass = "my-Class";

        myClass.Replace("-", " ");  //myClass works as string
        myClass ob = new myClass();  //myClass works as myClass

        ob.i();
    }
    public void i()
    {

    }
}

But I want to know:

Is this a compiler bug? as compiler should give warning.
How compiler manages this dual nature?

Why should the compiler give a warning? You're using myClass in two totally different contexts, and there is no ambiguity to the compiler. — Chris Farmer, Apr 08 '11 at 01:57
The difference is context. The parser can determine based on the context if it's the token is an object or a class. — Babak Naffas, Apr 08 '11 at 02:05
but Visual Studio's intellisence is showing only string methods and properties, when I use `myClass. `. — Javed Akram, Apr 08 '11 at 02:09

score 3 · Accepted Answer · edited May 23 '17 at 11:55

You're basically just doing something that looks weird, but the compiler can figure it out based on the context.

string @myClass = "my-Class";

This is declaring a string variable named myClass. The use of @ on the variable name allows you to create variables with a name that would normally not be allowed (e.g. a keyword). In your case, the @ is not needed, as myClass is not a keyword, but you can still use it. See this question for info: What does the @ symbol before a variable name mean in C#?.

myClass.Replace("-", " ");

This is calling the string Replace method on your myClass variable.

myClass ob = new myClass();

This is creating a new object of type "myClass". The compiler can tell by the usage that this use of myClass refers to the type, not the string variable.

score 2 · Answer 2 · answered Apr 08 '11 at 02:21

Note that you don't even need the @:

string myClass = "my-Class";

The above is perfectly fine.

You say:

compiler should give warning.

Should it? There is actually no ambiguity.

Consider this pretty typical scenario:

public class MyRandom
{
    public Random Random { get; private set; }

    public MyRandom()
    {
        // Is this ambiguous? No--the left HAS to be the property;
        // the right HAS to be the type name.
        Random = new Random();
    }
}

It's really not uncommon for names of variables to also be names of types. Only when some member overlaps is there ambiguity. For example:

public class MyThreadPool
{
    public static void Add(Thread thread)
    {
        Console.WriteLine("Called the static method.");
    }
}

public class SomeOtherClass
{
    public List<Thread> MyThreadPool { get; private set; }

    public SomeOtherClass()
    {
        MyThreadPool = new List<Thread>();
    }

    public void DoSomethingAmbiguous()
    {
        // To me, it would make sense for the compiler to issue a warning here,
        // as it seems rather ambiguous (to me at least). However, it doesn't,
        // which tells me the behavior is defined somewhere in the spec (I'm too lazy
        // to check).
        MyThreadPool.Add(null);
    }
}

score 1 · Answer 3 · answered Apr 08 '11 at 01:52

1

The line below is referring to the string variable you have defined with string @myClass and not the myClass class.

myClass.Replace("-", " ");  //myClass works as string

answered Apr 08 '11 at 01:52

sipsorcery

30,273
24
104
155

Yes, but why isn't there a name clash at compile-time? – Cameron Apr 08 '11 at 01:53
One is a type, the other is a local variable name. That's legit. – Chris Farmer Apr 08 '11 at 01:54
@Chris: Aha! So simple, and obvious in retrospect when one often names properties the same as their type. Thanks! – Cameron Apr 08 '11 at 03:11

score 1 · Answer 4 · answered Apr 08 '11 at 01:55

1

You are using myclass as a type as well as a variable name - the compiler can distinguish between the two of them, only if they clash you would have a problem - i.e within your Main method this would create a compiler error:

myClass.Main(new string [1]);

answered Apr 08 '11 at 01:55

BrokenGlass

158,293
28
286
335

score 0 · Answer 5 · answered Apr 08 '11 at 01:54

0

The first @myClass is an instance or variable name, this will not conflict with a class(type) name myClass.

So no error or warning.

answered Apr 08 '11 at 01:54

airbai

3,906
5
26
30

Dual nature of myClass in C#

5 Answers5