Inherited constructors
*** inherited constructors
This is a pet complaint of mine - I've never understood why you can't inherit constructors. People put forth all sorts of arguments against it, but to my mind, they can all be removed by one simple rule: any derived class inherits all constructors from it's parent, if and only if it doesn't construct any of it's own!
That way, it makes it nice and easy to just "add a function" to a class...
The case where you want to add a function to a class is a fairly rare one. The more common one is where you do something beyond that. In those cases, if we allowed constructor inheritance, then there's a reasonable chance that somebody will forget to do some initialization in a base-class constructor, and then bad things will happen. This is especially bad in the versioning case - if a new version of the base class shows up with a new constructor, you would automatically get a new constructor in your class. Bad.
Anonymous
April 22, 2004
Not only that, but often times it isn't apparent what is happening inside of a base constructor (aside from viewing the IL).
If you want to override the constructor and add methods you would probably want to just use a different class, or use implementation.Anonymous
April 22, 2004
I see your point and vagely agree that inherited constructor is not good. Vagely, because I have yet to encounter a situation where I do not want to inherit them.
Question 1: If I inherit a constructor and do nothing about it, that is, I don't add any code so there are no overrides, how can I forget any base initializations? I still use the very same implementation that was before.
Question 2: If I choose to add code, hence do an override (or new if you insist on the non virtual by default nonsense), then it is my responsibility to call any base constructors, right?
Question 3: If you still think it is so bad, can you at least automate the coding for us? Once we finish the constructor name, let us choose from a list, then let the tool complete the signature with the call to base.Anonymous
April 22, 2004
I understand your problem with inheriting constructors, but why not abstract or required constructors? I still haven't heard a good reason for this. In fact in serialization (XML and SOAP/Binary) both require a constructor that is specified in the docs, with no way to get the compiler to make sure you do the right thing. If you guys needed it, don't you think we might need it too?Anonymous
April 22, 2004
The comment has been removedAnonymous
April 22, 2004
The comment has been removedAnonymous
April 22, 2004
The comment has been removedAnonymous
April 22, 2004
I believe a good middle ground is a little more intellisense during class creation to address what constructors the base class has, and help you write it out... another way VS.Net becomes INVALUABLE! ...I still dont know how some people write C# in notepad ;-)Anonymous
April 22, 2004
Darren:
I wasn't arguing specifically against inheritance, but mainly against forcing a contract on constructors onto derived classes.
Inititialization isn't part of your object contract IMHO, but another part of your object collaborations. If a derived class wants to eschew your planned collaborations (because it has its own most likely.) then forcing a constructor it doesn't want onto it is dangerous. I know developers who would use that feature religously, mainly due to a variant of Not Invented Here syndrome known as I Know Better Than You.
With that said, I'm really finding it hard to grasp the semantics of what you are talking about.
Basically, you are suggesting that if you do not define any constructors, then the base classes constructors would then be inherited?
There is one small problem with that. Even if you don't define any constructors, the C# compiler does. Hmm, I guess that would just mean that it would have to be purely a compile time language feature.
Really though, I do see what you are saying. I think I just have a different opinion that the semantics of not explicitly defining a constructor is important in its own right.
I think the final text block above is pretty much my whole opinion on it. I like explicitness. Constructor inheritance is implicit, and not clear to me. To find out how to construct the object, I have to check my source file if I have a constructor snuck in somewhere, and then go to the base class if I didn't see one. Partial classes makes this even harder.
Honestly, I could see it going either way. I think I would prefer additional IDE support for copying base class constructors over cosntructor inheritance.Anonymous
April 23, 2004
Huh? Constructor inheritance is implicit, and not clear, hence it's bad? How's that different from method inheritance? And why do you have to go to the base source? Have you lost your intellisense?
And initialization is definitively a part of the object contract: You can't create the object if you don't fulfill it.
And why is forcing a new constructor dangerous? No one has to use it if they don't want to.
Why don't we just say no to anything but the default constructor? They behave just like static methods, so let's use those instead.
The way things are now, a constructor is technically not inherited, but it is still enforced on us. Don't you just hate it when the compiler says "No overload for method 'MyBase' takes '0' arguments" and point to a constructor which accepts exactly 0 parameters? You have to read the message twice to understand you forgot to CALL the base constructor.Anonymous
April 23, 2004
I really have no idea why I never express myself clearly :(
RE: Forcing your derived classes to have a specific constructor.
Constructors are special, and break a lot of rules. They are basically saying "This is what I need to do my thing".
In that vein, constructors are more a part of your object collaboration structure and not part of your object's responsibilities. It's saying "This is what I need." and not "This is what I do."
Thats probably part of why they decided to not allow constructor specifiers in interfaces. It'd just be silly.
With all that said, I'm completely ambivalent towards constructor inheritance now. I can see it go either way, with no strong opinion.Anonymous
April 23, 2004
I agree with Thomas. Constructors should be no different than any other inherited methods (other than they should all be virtual). Most of the arguments I've read so far against inheriting constructors is that nobody would want a new constructor in a base class to be inherited by an existing sub class without you knowing about it since it would circumvent the sub class's construction. I don't think this is any different than methods though – you wouldn’t want a new method in a base class to be inherited by an existing sub class without you knowing about it since it could circumvent the functions on the sub class. In other words, changing public signatures on existing classes (even if just expanding them) is already dangerous for methods (and properties) so it shouldn’t be used as an argument against inheriting constructors as well.
I can see a large benefit for allowing constructor inheritance and no drawbacks that don’t already exist for inheriting methods and properties. C# (or the CLR) shouldn’t sacrifice power and flexibility to attempt to protect developers from themselves by not paying attention. Leave that to VB.NET :)Anonymous
April 23, 2004
Of course there are drawbacks...for one, the number of constructors on a type could grow enormously, every object would have an empty default constructor anyway, since System.Object does; for another, you will end up with constructors that have no bearing on the object. Its not that they interrupt the construction so much as they shouldn't be there at all. To really allow constructor inheritance you would also have to allow a way to remove any constructor from any instance...which would violate the Liskov Substituality principal and make virtual constructors messy and dangerous.
Imagine:
public class MyClass
{
public MyClass(MyBaseObject x)
{
}
}
public class MyDerivedClass
{
public MyDerivedClass(MyDerivedObject y)
{
}
}
If you allow constructors to inherit, MyDerivedClass suddenly has a constructor that takes MyBaseObject...although the entire point at derivation was to extend the class so it could handle the new types, chances are good that MyDerivedClass uses features introduced in MyDerivedObject and hence, passing it MyBaseObject breaks its purpose.
Do you really think thats a good idea?Anonymous
April 23, 2004
Daniel - I think you are missing a very important point - Exactly like the default constructor, constructors would be inherited IF AND ONLY IF NO CONSTRUCTORS ARE DEFINED.
ie:
class A
{
public A() {}
public A(int y) {}
}
A has two constructors
class B : A
{
}
B has two constructors (no parameters and int)
class C : A
{
public C( string x);
}
C only has ONE constructor (string)
ie - you CANNOT say new C(10);
but you CAN say new B(10);
It is purely for the use when you want to just add or replace methods to an existing class... but we DO NOT CHANGE NORMAL OPERATION as far as properly extending a class - as soon as you start adding fields, you need to initialize them, and as soon as we put a constructor to do so, we have automatically removed ALL base constructors.
(NOW - remember - you already use this EVERY DAY - the default constructor behaves exactly like this. How many times do you inherit from a class (eg ListBox) and don't make your own constructor - I do it every day! But that works because the base class has a default constructor. All I'm saying is that all constructors should behave equally)
A concrete example - if I go and inherit from listbox, and change it to be exactly the same, but have say a gradient in the background, of course if someone goes and changes ListBox to add a constructor so it can be setup with a set of items, I very much DO and ALWAYS WILL want my derived class to be able to be constructed the same way!
However, if I happen to have made a listbox for a specific purpose (say to show a list of employees) - in which case I'd have a constructor that took a list of employees, I wouldn't want anybody to be able to construct the listbox in any other way!!
So - I think the rule is pretty simple, pretty unambigous, and would behave as you wanted in 99.99% of cases: "If you don't specify a constructor in your child class, you automatically get all the constructors from the parent class". "If you DO, then only the constructors specified at that level are valid" It actually makes the model simpler, because suddenly the default constructor behaves exactly the same as all the other constructors.
I CHALLENGE ANYBODY to come up with a concrete example where they wouldn't want classes to behave as specified above!Anonymous
April 24, 2004
The comment has been removedAnonymous
April 24, 2004
The comment has been removedAnonymous
April 24, 2004
The comment has been removedAnonymous
April 26, 2004
The comment has been removedAnonymous
April 30, 2004
From a library vendor perspective, having inheritable constructors is rather useful because it allows me to create new classes without cluttering up the source files with unnecessary code (in this case child constructors that do nothing else than invoke base class constructors).
Exception classes are a great example of that. In C#, the ApplicationException class has four constructors, three of which I would have to implement as pure deferals in a derived class.
Maybe, instead of default inheriting constructors, we could have some kind of syntax to pull in the base classes constructors explicitly. What do you guys think?Anonymous
May 11, 2004
The entry lead me to believe you couldn't inherit constructures. Unitl I found this link: http://www.csharphelp.com/archives/archive65.htmlAnonymous
December 18, 2004
Helpful For MBA Fans.Anonymous
August 13, 2008
PingBack from http://gregmaclellan.com/blog/inheriting-constructors-in-c-vbnet/Anonymous
January 20, 2009
PingBack from http://www.hilpers.com/302024-vererbungsproblemAnonymous
June 09, 2009
PingBack from http://weakbladder.info/story.php?id=3122