Re: Accessing private member via subclass
Alessio Stalla wrote:
On Nov 23, 11:14 pm, Arved Sandstrom <dces...@hotmail.com> wrote:
Mike Schilling wrote:
[ SNIP ]
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.
It might be more accurate to say that I consider the entire example to
be smelly (no reflection on Mike's experimenting here)...there's nothing
good about having a method in a superclass that calls out a subclass.
But it's legal code (in C#, but not in Java) so it's worthy of academic
discussion.
To use your terminology, I expect "i" to be accessible only in S. In
both languages. That is to say, in the body of class T we cannot access
S's private field "i". So far so good. However, and again in both
languages, I don't expect an instance of T to behave like its base class
S just because a base class private member is accessed in the lexical
scope of S. This is not intuitive to me at all. I would expect one to
have to cast the instance to the base class, just like Mike demonstrated
in the case of Java.
I'm certainly arguing that object.field access is done by object type.
That's how it works. Given the "object.field" expression, and object
being of class T, my ability to see "field" outside the body of T
depends on its existence and then its access modifier. In Java's case T
doesn't even have a field "i". In C#'s case it does, but in this
particular situation I don't expect an automatic cast to the base class
S just because we are in the body of S...however, that's what we seem to
get in the case of C#.
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
Well, in Java, public and protected (and in some cases package-private)
members of the base class *are* inherited by the subclass. This is
unambiguous in all documentation. The difference between C# and Java in
this case lies in private members - a Java subclass does not inherit
them at all; a C# subclass does, it just cannot access them.
So in Java the situation (to me) is quite clear - an instance of class
Sub (in this example) does not have a field "i". Period. That's what the
javac message is telling us.
In C# an instance of class Sub does have a field "i". However, the C#
docs tell us that a derived class cannot access private members of the
base class. The example given (a base class protected method accessing a
base class private field, and we obviously want to be have the protected
method work when accessed through the derived class) is a motivation (in
C#) for having those private members present, if not directly
accessible. In Java we simply have it, for the same example, that the
subclass can use such a protected method and things will work.
AHS