Inconsistent access levels???

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I've run into something that doesn't make a lot of sense and I'd appreciate
if someone could explain the logic.

Let's say I have:

internal interface MyInterface
{
void foo();
}

internal class MyClass : MyInterface
{
internal void foo()
{
Bar();
}
}

I get an error because the implementation of foo() is internal and should be
public.

What's the logic behind that? The class is internal, so isn't foo(), for all
intents and purposes, internal?

What am I missing?

Pete
 
Yes, I realize that but isn't that a bit inconsistent? I mean, if the class
is internal, the method is effectively internal, why not allow or even
enforce, that the methods be internal?

The methods are "more accessible" than the class which just seems to defy
sense, but maybe there's a reason for it. If there is, I guess I'm trying to
understand the reason.

Pete
 
internal class MyClass : MyInterface
{
internal void foo()
{
Bar();
}
}

I get an error because the implementation of foo() is internal and should be
public.
Click to expand...

MyClass is already internal, so foo() doesn't need to be. There's no way
anything outside of the assembly can have access to MyClass, and that
includes the foo() function. making it public will not allow it to be
accessed from elsewhere.

Chris
 
The methods are "more accessible" than the class which just seems to defy
sense, but maybe there's a reason for it. If there is, I guess I'm trying to
understand the reason.
Click to expand...

I see what you mean, but I guess that's just the way it is. look at this:

public class A
{
private class B
{
public int x;
private int y;
}

public void foo()
{
B b = new B();
b.x = 1;
b.y = 2; // COMPILE ERROR
}
}

it makes sense to me that they would do it this way because of what I just
demonstrated. the B class is private, but it's private members shouldn't be
available to A. I'm assuming they did something similar with 'internal'
just to be consistent.

Chris
 
Yes, I realize that but isn't that a bit inconsistent? I mean, if the class
is internal, the method is effectively internal, why not allow or even
enforce, that the methods be internal?
Click to expand...

No, the class *isn't* effectively internal.

Consider the following files:

Assembly1.cs:

using System;

public interface IFoo
{
void Bar();
}

public class Factory
{
public static IFoo GetFoo()
{
return new FooImpl();
}
}

internal class FooImpl : IFoo
{
public void Bar()
{
Console.WriteLine ("Hello");
}
}

Assembly2.cs:
public class Driver
{
static void Main()
{
Factory.GetFoo().Bar();
}
}

Now compile:

csc /target:library Assembly1.cs
csc /r:Assembly1.dll Assembly2.cs

Now run:

Assembly2

prints

Hello
 
I think that's a different situation, though. A class can only be private if
it's contained within another class. There's not really anything comparable
because a class within a namespace can only be public or internal.

Pete
 
But not if interface IFoo is declared internal! That's my point.
Click to expand...

Ah, apologies. I hadn't seen that the interface was internal as well as
the class itself.
 
Back
Top