Re: "this" and "base"
- From: "C.C. \(aka Me\)" <me@xxxxxxxx>
- Date: Sun, 22 Jan 2006 23:49:47 -0500
"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" <xllx.relient.xllx@xxxxxxxxx> wrote in message
news:1137989309.141396.4630@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> 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.string, 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?
>
.
- Follow-Ups:
- Re: "this" and "base"
- From: relient
- Re: "this" and "base"
- References:
- "this" and "base"
- From: relient
- "this" and "base"
- Prev by Date: Re: Can someone explain this use of "new"?
- Next by Date: Using xdoclet for C#
- Previous by thread: Re: "this" and "base"
- Next by thread: Re: "this" and "base"
- Index(es):
Relevant Pages
|
Loading
