Re: Accessing private member via subclass
On Nov 23, 11:14 pm, Arved Sandstrom <dces...@hotmail.com> wrote:
Mike Schilling wrote:
Arved Sandstrom wrote:
Mike Schilling wrote:
Patricia Shanahan wrote:
The rule that makes it illegal is the i is not even a member of
Sub,
and membership in Sub is needed to make the s.i notation valid.
"Members are either declared in the type, or inherited because
they
are accessible members of a superclass or superinterface which are
neither private nor hidden nor overridden (=A78.4.8)."
http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.4.=
3
That explains it. The analogous statement in C# is:
10.2.1: A class inherits the members of its direct base
class.
Inheritance means that a class implicitly contains all member=
s
of
its
direct base class, except for the instance constructors,
destructors
and static constructors of the base class.
which explain the difference in behavior.
I don't want to go off on a C# tangent here, but I'm not satisfied.
The C# 3.5 docs (in various places) say things like:
A derived class has access to the public, protected, internal, and
protected internal members of a base class. Even though a derived
class inherits the private members of a base class,
Unlike in Java, where it doesn't inherit them.
it cannot access
those members. However, all those private members are still present
in the derived class and can do the same work they would do in the
base class itself. For example, suppose that a protected base class
method accesses a private field. That field has to be present in the
derived class in order for the inherited base class method to work
properly.
and
Private members are accessible only within the body of the class or
the struct in which they are declared.
In other words, in "super".
and
Nested types in the same body can also access those private members.
and
It is a compile-time error to reference a private member outside the
class or the struct in which it is declared.
In other words, in "super".
Your quoted C# language spec snippet does not in fact gainsay any of
these.
It seems to me that they all agree that the code should compile
without error.
I do not see how the nearest C# equivalent of what we have here
in Java would compile.
Here they are: try it for yourself.
public class Sub : Super
{
}
public abstract class Super
{
private int i;
internal void method(Sub s)
{
s.i = 2;
}
}
I didn't doubt you that all this compiles, but I went ahead and played
with this in C# anyhow.
However, despite the fact that this does compile, I'm not so sure that
it should. The main phrase from MS that I keep on coming back to is
"Even though a derived class inherits the private members of a base
class, it cannot access those members." The only way I can reconcile
that statement with the actual compiler behaviour is to assume that MS
considers the above scenario to be the superclass doing the
access...which to me is a bit of a smelly situation.
Why is it smelly? To me it seems the most natural interpretation, and
I'm surprised about Java's behaviour (mind that I routinely program in
Java and have done very little C#).
Consider a generic expression object.field where object is of type T.
Suppose the expression is textually contained in a method declared in
class S. If you argue that the access to the field is done by
'object', rather than by S, then the visibility of object's type T
would apply, and you would have access to all of T's members, since T
can always "see" them. In other words, there would be no encapsulation
whatsoever for members declared in T.
But things don't work like that in Java; normally it is S that
controls the accessibility of members. So Java's behavior to me
suggests that the Java compiler, when evaluating access rules, acts as
if fields were actually inherited - or, better, copied - in
subclasses, which clearly is not the case.
Alessio