inconsistent accessibility error

  • Thread starter Thread starter Andy Fish
  • Start date Start date
A

Andy Fish

Consider the following code fragment

public class Wrapper {
protected enum E { IN, OUT };
public class C {
protected void foo(E e) { }
}
}

I want the class C to be accessible from outside the wrapper class, but not
the method foo. Compiling this gives the error:

Inconsistent accessibility: parameter type Wrapper.E' is less accessible
than method Wrapper.C.foo

but the accessibility of both types is "protected"
 
C can't see E simply because E does not subclass C - it is *embedded* in it;
protected items are only available to sub-classes.

Possible fixes:
Move E to inside C
Make E public - it is only an enum after all
(possibly something involving making E internal protected and C internal,
but that has it's own limitations)

Hope that helps,

Marc
 
Sorry - I mean't:
C can't see E simply because C does not subclass
Wrapper, and E is defined (protected) in Wrapper

Marc
 
Marc Gravell said:
Sorry - I mean't:
C can't see E simply because C does not subclass
Wrapper, and E is defined (protected) in Wrapper

No, C can definitely see E due to being nested within T. See section
10.5.2 of the spec (ECMA numbering):

<quote>
The accessibility domain of a nested member M declared in a type T
within a program P, is defined as follows (noting that M itself may
possibly be a type):

[...]
If the declared accessibility of M is protected, let D be the union of
the program text of T and the program text of any type derived from T.
</quote>

Now, in our case, C is within the program text of Wrapper, so it has
access to E.

The problem is that things which may logically be able to call foo (by
deriving from C) wouldn't have access to E.
 
Andy Fish said:
Consider the following code fragment

public class Wrapper {
protected enum E { IN, OUT };
public class C {
protected void foo(E e) { }
}
}

I want the class C to be accessible from outside the wrapper class, but not
the method foo. Compiling this gives the error:

Inconsistent accessibility: parameter type Wrapper.E' is less accessible
than method Wrapper.C.foo

but the accessibility of both types is "protected"

Consider the following:

public class Subclass extends C
{
public void Something()
{
foo(????);
}
}

foo is accessible here, but E isn't. Hence the error.

Does foo definitely need to be protected rather than private?
 
Fair enough! Learn something new every day...

;-p

Marc

Jon Skeet said:
Marc Gravell said:
Sorry - I mean't:
C can't see E simply because C does not subclass
Wrapper, and E is defined (protected) in Wrapper

No, C can definitely see E due to being nested within T. See section
10.5.2 of the spec (ECMA numbering):

<quote>
The accessibility domain of a nested member M declared in a type T
within a program P, is defined as follows (noting that M itself may
possibly be a type):

[...]
If the declared accessibility of M is protected, let D be the union of
the program text of T and the program text of any type derived from T.
</quote>

Now, in our case, C is within the program text of Wrapper, so it has
access to E.

The problem is that things which may logically be able to call foo (by
deriving from C) wouldn't have access to E.
 
Back
Top