# Friday, 13 December 2002
« No Title | Main | temporarily out of order »
protected

Interesting post by Chris Daly on the advanced-dotnet list today. He questions the C# language spec, which says that the following is illegal:

public class A
{
protected int x;
}
public class B: A
{
static void F(A a, B b) {
a.x = 1; // Error, must access through instance of B
b.x = 1; // Ok
}

The equivalent Java is legal. When I statically compile the Java equivalent of A and B into two different assemblies, to resulting B.dll is unverifiable. It's not just a C# language issue, the CLR restricts access to protected members in this way. When both types are compiled into the same assembly there is no problem, because protected is compiled as famorassem so any type in the assembly already has access (this is needed because protected also implies package access, which has no CLR equivalent).

I wonder if a work around is required.

UPDATE: I wasn't quite awake yet. Of course, the reason that the above code works in Java is because protected implies package access, it has nothing to do with the protectness of the field. When you move A and B into different packages, javac fails with the same error as the C# compiler.

Friday, 13 December 2002 14:32:21 (W. Europe Standard Time, UTC+01:00)  #    Comments [0]
Name
E-mail
Home page

I apologize for the lameness of this, but the comment spam was driving me nuts. In order to be able to post a comment, you need to answer a simple question. Hopefully this question is easy enough not to annoy serious commenters, but hard enough to keep the spammers away.

Anti-Spam Question: What method on java.lang.System returns an object's original hashcode (i.e. the one that would be returned by java.lang.Object.hashCode() if it wasn't overridden)? (case is significant)

Answer:  
Comment (HTML not allowed)  

Live Comment Preview