The C# compiler is really smart, but…

Published Fri, Jun 20 2008 11:37

I’m still not understanding why it won’t give me a warning when I create an internal class with a public method. Here’s an example:

class MyInternalClass{
public void Test(){} //no compiler warning
}

Ok, at the end of the day, Test is really an “internal” method since the acessibility of a member can never be greater than the one of its containing type. But why can’t I get at least a warning? In this case, setting the method type to internal should be the “maximum” accesibility,right? There are other similar scenarios where we get the correct response from the compiler. For instance, you cannot declare a protected method on a struct. This makes sense, of course, because you can not inherit from a struct (therefore, you really don’t need to declare protected methods).

So, here we are: on the one hand, the compiler will let me declare a method as public on an internal class, even though that method will only end up beeing used on the assembly where it is defined due to the accessibility of its containing type without even generating a warning. On the other hand, the compiler won’t “relax” the protected method error on a struct type.

I’m not a compiler geek (or even a C# language expert) so the problem might really be on spec and not on the compiler. Anyway, I think that the compiler could at least generate a warning on these scenarios (internal classes with public methods). And what do you think?

by luisabreu

Filed under: C#

Comments

# Filip said on Monday, June 23, 2008 11:38 AM

I think you are missing the point. The class visibility level is, in this case, separate from the method visibility level. Say you have 2 internal classes, and one of them has public and protected methods. Should the other class be able to access protected methods just because both classes are internal? No, it should not. That's why if you want classes to call each other's methods, you either need to make them public or internal. That's why there is no warning issues by the compiler.

Cheers,

- Filip.

# luisabreu said on Monday, June 23, 2008 1:08 PM

Hello Filip.

That's not the scenario I'm complaining about. I'm not saying that all the methods on an internal class should be internal.

what I'm saying is that there really is no purpose on letting an internal class declare a public method since you can apply internal to a class' member. Ie, the "maximum" visibility any member of an internal class will get is internal, which is "less" than public. That's what I'm complaining about.

# skeet said on Wednesday, June 25, 2008 4:08 AM

Well, you already need to be able to allow public methods if you implement an interface (leaving explicit interface implementation aside for the moment).

Likewise an internal class may derive from a public class and override one of its public methods.

I don't see that there's much benefit to prohibiting public methods where they *aren't* useful... and that's even leaving aside the reflection side of things (something may well want to find all the public properties of a class which is internal - binding, for example; similar uses for methods wouldn't be impossible to think of).

Jon

# luisabreu said on Monday, June 30, 2008 11:26 AM

Hello Jon.

Well, I guess that some of those scenarios are valid.

Now, my problem with letting you define public methods on internal classes is that it doesn't "flow". Let me explain this better: You can't inherit from a base class that "is less visible" that the derived class. Example:

internal class T{}

public class R:T{}

This does "flow". In my limited brain, this does makes sense and I'm failing to see where internal class + public method is really a valid design approach. Again, I'm known for being slow, so maybe in a week or two it starts to make sense.

# Thomasek said on Friday, October 31, 2008 7:07 AM