"this" and "base"

[relient]

Question: Why can't you access a private inherited field from a base
class in a derived class? I have a *theory* of how this works, of
which, I'm not completely sure of but makes logical sense to me. So,
I'm here for an answer (more of a confirmation), hopefully.

First let me say that I know people keep saying; it doesn't work
because the member "is a private". I believe there's more to it than
just simply that...

Theory: You inherit, not only the members in the base class, but the
whole base class itself - as an object, which contains the members.
Therefore, this has *almost* the same effect as if you declared a base
class manually in the derived class as shown in figure 1:

public class Base
{
private string name;
// more members and methods...
}

public class Derived
{
// instance members:
Base baseField;
private uint numbersField;
}
and if you tried to access the private member "name" of baseField
inside a method in the derived class like: baseField.strin g, you would
get an error, because it is private and can only be accessed within
it's own class scope (container). And similarly, this holds true for
why you cannot access a private base member in a derived class in a
"base and derived class relationship". This theory makes good, perfect
logical sense (to me) of why you *cannot* access a private member
*because* you're trying to access a private member outside of the
container where it is defined. And also, the keyword "base" then
essentially becomes the reference to that base class object. Just like
"this" is a reference to an instantiated object. And this(not the
keyword), also, essentially means this: when you derived a class from a
base class, you then have "two" classes within one unit, and this unit
is the drived class.

To elaborate some more, let's throw in a problematic problem:
So with that just said, How then does the keywords "base" and "this"
refer to the same "data" (fields etc..) and "code" (methods etc..) - at
times - when they *are* two different objects which are within one unit
- the derived class (this == drived class object AND base == base class
object)? But, they also, sometimes can refer to different "code" (when
you override). I believe the reason is because when you do not override
a virtual method in the base class, the compiler (or early binding)
makes both objects "this" and "base" point to the same "code". But in
the case where you do override a virtual method in the derived class,
the compiler (or early bindig) makes each object (this AND base) point
to different methods (code).

Sorry for the long post but I decided to try to make some sense out of
this after I encountered a problem ( which I could've posted instead of
all this but decided against; in fear of being told "it's becase it's a
private". That alone, I believe is not a clear answer, but a vague one.
But anyways, I am going to include this code:

public class Car
{
private uint odometer;
}

public class RacingCar : Car
{
private uint odometer;

public static void Main( )
{
}
}

The above compliles with no errors and only two warnings (no
assignement). But the problem I see is this: Why do I *not* get an
error from the compiler, along the lines of "error: redefinition of
Car.odometer", because I inherit a member with the exact same signature
that's also declared in RacingCar? And as I said; someone looking at
this would probably say "because Car.odometer is private and it's
inside its own class scope". And it's true that it's within its own
scope, which would prove my theory of two seperate class objects
(through "base" and "this") exist when you have a derived class, but,
that alone is not enough of an answer to me so I wrote all this for
some enlightment and confirmationt. What's your take or view on this?

[Steven Nagy]

> What's your take or view on this?

It doesn't work because the member "is a private".
But your explanation would be a good way to put it to beginner
programmers who had never heard of OO...

[C.C. \(aka Me\)]

"What keeps you from accessing a Private member" is more of what you are
looking for I think? You know why (because it is private) but you are not
sure what (compiler, runtime, something else) is keeping you from accessing
it. Well.. It is both the Compiler and Runtime engine that keep you from
doing it. If you tried to compile something that accessed a private member
you would get a compile error. During runtime the access level (public,
private, protected) gets checked to determine if you are allowed access to
it.

You can verify this by doing the following:

Create a Control Library with a public method in it and compile it.
Create an application that calls the public method in this Control Library
and compile it.
Run the application and it should work fine.
Now go back to your Control Library and change that method to Private and
recompile _JUST_ the Control Library.
Now run the application.
It should give you an exception because the runtime engine is doing access
level checking!

When you Override it does not change what base points to. The reason you
would use base in the first place would be to get to the "original" version
of a method that you have overridden.

Lastly, the reason that your last example compiles and works fine is because
of Scope. When a member is declared makes all the difference. If you had a
member function in your derived class you could have a local variable called
odometer in it as well and it would work just fine!

So.. To answer your question in 3 words.. "Because it's Private!" :-)

Hope this helps ya out!
"relient" <xl************ ***@gmail.com> wrote in message
news:11******** ************@g4 3g2000cwa.googl egroups.com...

Question: Why can't you access a private inherited field from a base
class in a derived class? I have a *theory* of how this works, of
which, I'm not completely sure of but makes logical sense to me. So,
I'm here for an answer (more of a confirmation), hopefully.

First let me say that I know people keep saying; it doesn't work
because the member "is a private". I believe there's more to it than
just simply that...

Theory: You inherit, not only the members in the base class, but the
whole base class itself - as an object, which contains the members.
Therefore, this has *almost* the same effect as if you declared a base
class manually in the derived class as shown in figure 1:

public class Base
{
private string name;
// more members and methods...
}

public class Derived
{
// instance members:
Base baseField;
private uint numbersField;
}
and if you tried to access the private member "name" of baseField
inside a method in the derived class like: baseField.strin g, you would
get an error, because it is private and can only be accessed within
it's own class scope (container). And similarly, this holds true for
why you cannot access a private base member in a derived class in a
"base and derived class relationship". This theory makes good, perfect
logical sense (to me) of why you *cannot* access a private member
*because* you're trying to access a private member outside of the
container where it is defined. And also, the keyword "base" then
essentially becomes the reference to that base class object. Just like
"this" is a reference to an instantiated object. And this(not the
keyword), also, essentially means this: when you derived a class from a
base class, you then have "two" classes within one unit, and this unit
is the drived class.

To elaborate some more, let's throw in a problematic problem:
So with that just said, How then does the keywords "base" and "this"
refer to the same "data" (fields etc..) and "code" (methods etc..) - at
times - when they *are* two different objects which are within one unit
- the derived class (this == drived class object AND base == base class
object)? But, they also, sometimes can refer to different "code" (when
you override). I believe the reason is because when you do not override
a virtual method in the base class, the compiler (or early binding)
makes both objects "this" and "base" point to the same "code". But in
the case where you do override a virtual method in the derived class,
the compiler (or early bindig) makes each object (this AND base) point
to different methods (code).

Sorry for the long post but I decided to try to make some sense out of
this after I encountered a problem ( which I could've posted instead of
all this but decided against; in fear of being told "it's becase it's a
private". That alone, I believe is not a clear answer, but a vague one.
But anyways, I am going to include this code:

public class Car
{
private uint odometer;
}

public class RacingCar : Car
{
private uint odometer;

public static void Main( )
{
}
}

The above compliles with no errors and only two warnings (no
assignement). But the problem I see is this: Why do I *not* get an
error from the compiler, along the lines of "error: redefinition of
Car.odometer", because I inherit a member with the exact same signature
that's also declared in RacingCar? And as I said; someone looking at
this would probably say "because Car.odometer is private and it's
inside its own class scope". And it's true that it's within its own
scope, which would prove my theory of two seperate class objects
(through "base" and "this") exist when you have a derived class, but,
that alone is not enough of an answer to me so I wrote all this for
some enlightment and confirmationt. What's your take or view on this?

[relient]

C.C. (aka Me):
<quote>worte stuff</quote>

Ok, So I thought about what you said and I wrote something new, which,
ironically makes sense also:P

Tell me what you think about it:

When you inherit from a base class, you inherit their members
regardless of their access modifiers. If they are public members, you
can refer to them with the "this" keyword and "base" keyword (that is
if you do not hide them as will be explained next). But you can hide
their base implementation and implement your own version by declaring
members, in the derived class, with the same name and signature as the
base members you wish to hide. Then, the "this" keyword refers to your
implementation instead of the base implementation (which are totally
seperate now). But you can still gain access to the original
implementation by using the "base" keyword.

If the base members are private members, they can only be refered to
with the "base" keyword because of their scope (defined within base
class scopeness).

[Jon Skeet [C# MVP]]

relient <xl************ ***@gmail.com> wrote:

<snip>

If the base members are private members, they can only be refered to
with the "base" keyword because of their scope (defined within base
class scopeness).

No. Using "base" doesn't give you any more access to the members. If
they're private, then only code in that type (and in nested type) can
get at them.

Basically, just because you've inherited the members doesn't mean you
have access to them - inheritance and access are separate concepts.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Kevin Spencer]

The answer is much simpler than you imagine. As a programmer, you should
know it already. When you write a program, you create a set of business
rules that determine how the program operates, what it does, how it does it,
when it must, can and cannot perform certain operations, what the exceptions
to the general rules are, etc. These rules are enformced with conditional
logic in the program. If you don't write the code correctly, the rules are
broken.

These rules generally follow a certain logic, but ultimately, they are
arbitrary. The creator of the program is the arbiter of the rules.

The same applies to a programming language (or any language for that
matter). There are business rules that govern how a programming language is
compiled and run, and these rules are determined by the author of the
compiler and the programming language. These decisions are arbitrary.

For example, since C# and VB.Net compile to the same MSIL, why can't you use
pointer arithmetic in VB.Net? Well, one might imagine all sorts of
apparently logical reasons, but when it comes down to it, the answer is that
the developers of VB.Net made a decision that VB.Net would not support
pointer arithmetic. It is entirely possible that they could have decided
otherwise. They have even talked about supporting it in future versions. But
the point is that, ultimately, they made a decision to create the rule in
that fashion, and that they made it arbitrarily.

Here's another example: In some states, the legal drining age is 18. In
others, the legal age is 21. Why? Because the legislatures of these states
made the decision that the rule would be thus.

Rules and law are not so much about right and wrong, subjectively logical
versus subjectively illogical, but simply because a decision must be made.
Without rules, there is chaos.

The answer to your question is therefore, the reason that you cannot access
a private inherited field in a base class from a derived class is that the
developers of the CLI made an arbitrary decision that the rule should be
thus. You can imagine all you like what the logic behind it is. However, no
matter how much you speculate, you will never know unless they tell you. And
even if you know, it changes nothing. The rule remains. It is what it is.
Until the creator decides otherwise.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Who is Mighty Abbott?
A twin turret scalawag.

"relient" <xl************ ***@gmail.com> wrote in message
news:11******** ************@g4 3g2000cwa.googl egroups.com...

Question: Why can't you access a private inherited field from a base
class in a derived class? I have a *theory* of how this works, of
which, I'm not completely sure of but makes logical sense to me. So,
I'm here for an answer (more of a confirmation), hopefully.

First let me say that I know people keep saying; it doesn't work
because the member "is a private". I believe there's more to it than
just simply that...

Theory: You inherit, not only the members in the base class, but the
whole base class itself - as an object, which contains the members.
Therefore, this has *almost* the same effect as if you declared a base
class manually in the derived class as shown in figure 1:

public class Base
{
private string name;
// more members and methods...
}

public class Derived
{
// instance members:
Base baseField;
private uint numbersField;
}
and if you tried to access the private member "name" of baseField
inside a method in the derived class like: baseField.strin g, you would
get an error, because it is private and can only be accessed within
it's own class scope (container). And similarly, this holds true for
why you cannot access a private base member in a derived class in a
"base and derived class relationship". This theory makes good, perfect
logical sense (to me) of why you *cannot* access a private member
*because* you're trying to access a private member outside of the
container where it is defined. And also, the keyword "base" then
essentially becomes the reference to that base class object. Just like
"this" is a reference to an instantiated object. And this(not the
keyword), also, essentially means this: when you derived a class from a
base class, you then have "two" classes within one unit, and this unit
is the drived class.

To elaborate some more, let's throw in a problematic problem:
So with that just said, How then does the keywords "base" and "this"
refer to the same "data" (fields etc..) and "code" (methods etc..) - at
times - when they *are* two different objects which are within one unit
- the derived class (this == drived class object AND base == base class
object)? But, they also, sometimes can refer to different "code" (when
you override). I believe the reason is because when you do not override
a virtual method in the base class, the compiler (or early binding)
makes both objects "this" and "base" point to the same "code". But in
the case where you do override a virtual method in the derived class,
the compiler (or early bindig) makes each object (this AND base) point
to different methods (code).

Sorry for the long post but I decided to try to make some sense out of
this after I encountered a problem ( which I could've posted instead of
all this but decided against; in fear of being told "it's becase it's a
private". That alone, I believe is not a clear answer, but a vague one.
But anyways, I am going to include this code:

public class Car
{
private uint odometer;
}

public class RacingCar : Car
{
private uint odometer;

public static void Main( )
{
}
}

The above compliles with no errors and only two warnings (no
assignement). But the problem I see is this: Why do I *not* get an
error from the compiler, along the lines of "error: redefinition of
Car.odometer", because I inherit a member with the exact same signature
that's also declared in RacingCar? And as I said; someone looking at
this would probably say "because Car.odometer is private and it's
inside its own class scope". And it's true that it's within its own
scope, which would prove my theory of two seperate class objects
(through "base" and "this") exist when you have a derived class, but,
that alone is not enough of an answer to me so I wrote all this for
some enlightment and confirmationt. What's your take or view on this?

[Rudderius]

Why do you think so much about things that are so clear?

The people who have designed the language have defined that a private
member can only by accessed from within the class. Even derived classes
have no access to private base-class members.

Have you thought about this: what if your theory was the one used to
design a language? It would mean that making a different between
private, protected and public is of no sence because then you can create
a inheriting class that makes all private members public.

So, just take it as it is: make your private members protected (this is
why something like protected exists).

Have you ever asked someone why 3 = 2 + 1. I can easily write a theory
that says that 2 + 1 = 4.

Greetz,
Rudderius

relient wrote:

Question: Why can't you access a private inherited field from a base
class in a derived class? I have a *theory* of how this works, of
which, I'm not completely sure of but makes logical sense to me. So,
I'm here for an answer (more of a confirmation), hopefully.

First let me say that I know people keep saying; it doesn't work
because the member "is a private". I believe there's more to it than
just simply that...

Theory: You inherit, not only the members in the base class, but the
whole base class itself - as an object, which contains the members.
Therefore, this has *almost* the same effect as if you declared a base
class manually in the derived class as shown in figure 1:

public class Base
{
private string name;
// more members and methods...
}

public class Derived
{
// instance members:
Base baseField;
private uint numbersField;
}
and if you tried to access the private member "name" of baseField
inside a method in the derived class like: baseField.strin g, you would
get an error, because it is private and can only be accessed within
it's own class scope (container). And similarly, this holds true for
why you cannot access a private base member in a derived class in a
"base and derived class relationship". This theory makes good, perfect
logical sense (to me) of why you *cannot* access a private member
*because* you're trying to access a private member outside of the
container where it is defined. And also, the keyword "base" then
essentially becomes the reference to that base class object. Just like
"this" is a reference to an instantiated object. And this(not the
keyword), also, essentially means this: when you derived a class from a
base class, you then have "two" classes within one unit, and this unit
is the drived class.

To elaborate some more, let's throw in a problematic problem:
So with that just said, How then does the keywords "base" and "this"
refer to the same "data" (fields etc..) and "code" (methods etc..) - at
times - when they *are* two different objects which are within one unit
- the derived class (this == drived class object AND base == base class
object)? But, they also, sometimes can refer to different "code" (when
you override). I believe the reason is because when you do not override
a virtual method in the base class, the compiler (or early binding)
makes both objects "this" and "base" point to the same "code". But in
the case where you do override a virtual method in the derived class,
the compiler (or early bindig) makes each object (this AND base) point
to different methods (code).

Sorry for the long post but I decided to try to make some sense out of
this after I encountered a problem ( which I could've posted instead of
all this but decided against; in fear of being told "it's becase it's a
private". That alone, I believe is not a clear answer, but a vague one.
But anyways, I am going to include this code:

public class Car
{
private uint odometer;
}

public class RacingCar : Car
{
private uint odometer;

public static void Main( )
{
}
}

The above compliles with no errors and only two warnings (no
assignement). But the problem I see is this: Why do I *not* get an
error from the compiler, along the lines of "error: redefinition of
Car.odometer", because I inherit a member with the exact same signature
that's also declared in RacingCar? And as I said; someone looking at
this would probably say "because Car.odometer is private and it's
inside its own class scope". And it's true that it's within its own
scope, which would prove my theory of two seperate class objects
(through "base" and "this") exist when you have a derived class, but,
that alone is not enough of an answer to me so I wrote all this for
some enlightment and confirmationt. What's your take or view on this?

[Steven Nagy]

>> 2 + 1 = 4.

It does, if 1 inherits from 2, and its private count property isn't
made public.