Re: "this" and "base"
- From: "Kevin Spencer" <kevin@xxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 23 Jan 2006 07:55:50 -0500
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" <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?
>
.
- References:
- "this" and "base"
- From: relient
- "this" and "base"
- Prev by Date: Re: using GDI+ Graphics object and getting confused, help!
- Next by Date: Re: Cross process hookingi in dot net
- Previous by thread: Re: "this" and "base"
- Next by thread: Re: "this" and "base"
- Index(es):
Relevant Pages
|
Loading
