Re: Constructor inheritance (or lack thereof)
From: Jon Skeet [C# MVP] (skeet_at_pobox.com)
Date: 12/22/04
- Next message: Jon Skeet [C# MVP]: "Re: Threading question"
- Previous message: CK: "Re: Threading question"
- In reply to: Ravichandran J.V.: "Re: Constructor inheritance (or lack thereof)"
- Next in thread: Ravichandran J.V.: "Re: Constructor inheritance (or lack thereof)"
- Reply: Ravichandran J.V.: "Re: Constructor inheritance (or lack thereof)"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 22 Dec 2004 08:34:34 -0000
Ravichandran J.V. <jvravichandran@yahoo.com> wrote:
> "Well, the spec is slightly unclear. I find it helpful to use "default
> constructor" to mean a constructor which is supplied when no other ones
> are, and "parameterless constructor" to mean a constructor which takes
> no parameters."
>
> I agree with your definition of a default constructor as well as the one
> for parameterless constructor.
Good.
> >In what way is the compiler trying to overload the derived >class's
> constructor? What do you even mean by that?
>
> Can you answer me if you can overload a signature of any member of a
> class if the same signature did not exist in some form ? I will answer
> to your question after your answer.
You don't overload a signature - you overload either a method or a
constructor. If it's a method, there has to be another method with the
same name (not signature). If it's a constructor, there has to be
another constructor.
However, I still don't see what you mean when you talk about the
"compiler trying to overload" anything.
> >But where does the "as only like constructors can invoke >like
> constructors" part come in?
>
> I need a clarification from you if we can continue to argue on
> constructors in inheritance or should we only contest on the simple fact
> that if the OP wanted to know only about whether constructors are
> inherited or not, why wouldn't the OP simply ask "Are constructors
> inherited or not ?"
I'm happy to debate whatever you want, but I do contest your "simple
fact". The OP realised that constructor inheritance was at least not
provided by default by C#, but wanted to know if there was any way of
getting it.
> >In what way did I introduce the issue of constructor >chaining? See
> your original post on the thread, quoted >above!
>
> I introduced only the behavior of the constructors but you made it an
> issue of chaining and inheritance.
The only behaviour of constructors you talked about in your original
post was chaining.
> >Um, no. By the time you posted, the OP's question had been >answered by
> several people, who all understood that the OP >was basically asking why
> constructor inheritance wasn't in >C#, and whether there was some way of
> enabling it that >he'd missed.
>
> What do you mean, um no? Are you limited in your vocab only to the usage
> of disagreeing and disagreeable words?
I mean "I disagree with your statement", fairly obviously. While my
vocabulary clearly isn't limited to "disagreeing and disagreeable
words" I don't see why I shouldn't voice my disagreement.
> Even if >By the time you posted, the OP's question had been >answered by
> several people> is your opinion, it still does not matter because as I
> have already noted the OP is somewhat confused and extra help is not
> something that you can object to because the thread is devoted to the
> OP's query and not to service your quest for more points to argue.
>
> <quote>
> A simple thumb rule in .Net is the like constructor will invoke its
> like base contructor and all instantiation will go up all the way to
> the base System.Object class.
> </quote>
>
> >Now, please explain the relevance of that to constructor >inheritance.
>
> My explanation, as I have already written, is not on inheritance but on
> how constructors behvae and what are the likely errors that can occur.
Things that the OP had demonstrated his understanding of in his first
post, and which have little to do with what he was actually asking.
> Knowing this the OP can easily form his own understanding of
> constructors. But, if you want me to conform to your own understanding
> then I will - constructors are not inherited in C#.
Ah, great. Does that mean you retract your various insults on the
thread ages ago where you accused me all manner of stupidities for
believing what the spec says (i.e. that they're not inherited)? You
might want to go back and read that thread, by the way. It's easy to
find - just search on groups.google.com for the exact phrase "The
destructor is the only object of a base class that is not inherited"
(part of one of your articles).
Note that I don't want you to conform to my understanding - I want you
to conform to what the language specification says, which is clearly
demonstrated in numerous programs.
> >Given your article on constructors on Devdex,
>
> There is no such article. I have already had it taken off ever since you
> pointed out the error (let me assure you the error was a typo but again,
> I am sure you will not agree to that!:))
It still seems to be there:
http://www.developersdex.com/gurus/articles/459.asp?Page=1
It's also still in your list of articles:
http://www.developersdex.com/gurus/default.asp?p=3133
And yes, I disagree with it being a typo, as you've stated it more than
once. You stated something very similar in the newsgroup thread a long
time ago: "It is a means to achieve inheritance because without
implementing the base' default construcotrs, the derived class cannot
inherit the overloaded constructors of the base." (What you meant by
that exactly is hard to say, given that constructors aren't inherited
anyway.)
> >I'm not sure you entirely understand constructor chaining.
>
> Um (taking a tip from you), no, I wouldn't say that because you have not
> yet answered MY question as to why an error pertaining to System.Object
> should appear when you try to access a public member of a class with the
> instance of another class and neither class participate in inheritance.
Could you give an example? To answer your previous challenge though:
using System;
class Test
{
static void Main()
{
Class2 c2 = new Class2();
c2.member = 5;
Console.WriteLine (c2.member);
}
}
class Class1
{
public int member;
}
class Class2 : Class1
{
}
I can't see anything in your challenge which isn't covered there, but
the code compiles and runs with no problem.
I'm still not sure what the relevance to the OP's question is though.
> And please do not think that I am seeking an answer I know why the error
> appears but what I want to know is your understanding of the error so
> that I can better explain to you whether or not I understand constructor
> chaining.
>
> <quote>
> The System.Object constructor is also totally irrelevant
> to the derived class's constructor, as only the base class's
> constructors are considered - you can't "skip" the base class, so the
> System.Object constructor is only relevant to the base class.
> </quote>
>
> Please refer to the previous paragraph and upon your reply, we can
> contest whether System.Object is relevant to constructor chaining or not
> and please do not reply that the thread is on inheritance and not
> chaining or whatever.
It's relevant to constructor chaining when writing a class deriving
from System.Object. It's not relevant when writing a class deriving
from any other class. The reason your earlier sample code wouldn't
compile has nothing to do with System.Object's constructors - it's
because the class you called Base doesn't have a parameterless
constructor, and that's the constructor that the Derived constructor is
trying to call. Changing the Derived constructor to:
public Derived(int x) : base (x)
{
}
would make it compile fine. The error also has nothing to do with the
line "Derived ob=new Derived(10);" - that line itself is fine, as the
Derived class *does* have a constructor which takes an int parameter.
> <Quote>
> implement (it is similar to overriding although the terminology is
> different in this case) the base class' default constructor".)
> </Quote>
>
> If you put it this way, I am quite sure you are right but I will have to
> check whether I have really written implement because you have a way of
> attributing your own thoughts and blame them as mine.
So you've said before without ever actually demonstrating, as far as I
can remember.
> I agree that the implements word makes it sound as if the base'
> constructor is being overridden in the derived class but let me check
> whether I really used those words as you claim. If I did, I can only
> say that you are absolutely right and as an explanation let me put it
> this way that it was more due to a probable human typo error and
> nothing else.
You can check it on the article you say you've removed. I cut and
pasted the quote directly from that. It's not due to a typo though -
your sample code clearly shows that you meant what you said. You really
believed that in order for a derived class to use a constructor from
the base class which takes parameters, you had to have a parameterless
constructor in the derived class.
If it were just a typo, you wouldn't have this bit (on the second
page):
<quote>
Hence, to make the call
public b(float f,int k):base(f,k)
work, the derived class 'b', too, must have the default constructor
implemented in it
</quote>
I hope you understand constructors better than you did when you wrote
the article, but you clearly didn't understand them then.
> > The original OP's post is
> > -------------------------
> > "When attempting to instance one of the derived classes using
> > parameters, I get CS1501 (no method with X arguments). "
> > ----------------------------------------------------------
>
> <Quote>
> No. That's a very small *part* of the post.
> </Quote>
>
> But it is an illuminating part.
Not without taking the rest of the post into context - the rest of the
post which clearly shows that the OP knew why he was getting that error
message.
-- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too
- Next message: Jon Skeet [C# MVP]: "Re: Threading question"
- Previous message: CK: "Re: Threading question"
- In reply to: Ravichandran J.V.: "Re: Constructor inheritance (or lack thereof)"
- Next in thread: Ravichandran J.V.: "Re: Constructor inheritance (or lack thereof)"
- Reply: Ravichandran J.V.: "Re: Constructor inheritance (or lack thereof)"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
