Re: Constructor inheritance

"Andrew McDonagh" <news@xxxxxxxxxxxxxxxxxxxxx> wrote in ...
: isamura wrote:
: > "Andrew McDonagh" <news@xxxxxxxxxxxxxxxxxxxxx> wrote ...
: > : isamura wrote:
: > : > "zero" <zero@xxxxxxx> wrote ...
: > : > : "isamura" <nospam@xxxxxxxxxx> wrote in
: > : > : news:Ie6dncUBmtMdkcDeRVn-jA@xxxxxxxxxx:
: > : > :
: > : > : >
:
: snipped
:
: > : > compiler would do its magic and create all inherited constructors, when missing? I guess
this is
: > : > just my wishful thinking but we have to live with what is given. Just don't expect all of us
to
: > be
: > : > happy about it.
: > : >
: > : > ..K
: > : >
: > : >
: > :
: > : No, because we often don't want the same set of constructors on derived
: > : classes, that are available on base (super) classes.
: > :
: > Inheritance is supposed to promote code resuse (and good design).
:
: Not really, Inheritance is to provide an 'is-a' relationship between one
: derived type and its parent type, there by allowing the 'Liskov
: Substitutability Principle' to work.
:
: Code reuse is useful side effect of this relationship, but its not it
: aim. Indeed designs that make use of inheritance simply to get code
: reuse are usually the fragile designs, comprising of large inheritance
: trees.
:
Agreed. I did not mean to imply inheritance be used (abused) in this manner. I doubt code reuse can
be of much in this case.

: If code re-use is the aim, then delegation not inheritance should be
: favored.
:
: As a concrete example, consider Java's Thread class. To create and use
: a thread, a much more preferable OO design is to instantiate a Thread
: object and give it an instance of one of your own classes that implement
: the Runnable interface. This design then conforms to the 'Single
: Responsibility Principle'. Also, we still get total code re-use and a
: dynamic runtime relationship between the Thread class and the Runnable
: class.
:
Good example.

: Where as we could derived from Thread and implement the Run() method
: with the same logic that could exist within the first example's Runnable
: class.
:
A thread is a process that runs a sequence of code so your previous example makes sense. But
subclassing for the same purpose would not. It wouldn't even pass the IS-A test.

: But now we have a static compile time relationship, a Thread derived
: class that not only is a Thread but also the Runnable - its a duel
: responsibility class.
:
: Yet there's no more code reuse.
:
: > I will agree that at times it may be desirable to over-ride a behavior
: > of the super class that is not appropriate, but this does
: > (should) not happen often. At least not in my "camp".
:
: Agreed, but not what I was writing about. I was attempting to show that
: with constructors in Java we can chose to hide some or all of the same
: kind of constructors that appear on the base classes through the derived
: classes.
:
That is one point of view. Alternatively, allow subclasses to inherit constructors. For a given
class, if any of the inherited constructors are invalid, the class can over-ride the "illegal"
constructor to throw an exception to indicate it shouldn't be used. This approach may have alleviate
the OP original problem. However, it is a moot point since constructors are not allowed to inherit
by design.

: I rarely find the need to have the same number and signature type of
: constructors on derived classes - see my other post with the
: MyOwnException class deriving from RuntimeException.
:
Sure, but it does get old having to code (with/out aid of tools)

ClassB(String s) {
super(s);
}

: >
: > : Simplistically, a compiler jobs is to convert your .java source code
: > : into JVM compatible byte code.
: > :
: > So it was surprising the compiler generates missing default constructors.
:
: Not really, that is a special case dealing with the mechanics of
: creating an object - all classes need a constructor of some kind, the
: simplest one being the no-arg constructor. However, the compiler will
: only generate a default constructor if no other user defined
: constructor appears on the class. If you have created your own
: constructor, the compiler can't generate one because there is no
: universal good option available for every java application, and so the
: compile will fail with an error.
:
The "surprise" element was for a newbie (like me) to find out s/he been fooled by the compiler in
thinking constructors can sometimes be inherited.

..K


.

Relevant Pages

  • Re: Constructor inheritance (or lack thereof)
    ... "You don't overload a signature - " ... I will post back on the exact error ... "It is a means to achieve inheritance because without ... that exactly is hard to say, given that constructors aren't inherited ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: inheritance, yes, but how?
    ... > Making class based inheritance in Javascript is hard because Javscript ... > Now, if you understand this, you can see that treating constructors as ... > function extend(classA, extenderB) { ... > It requires a correct implementation of ECMAScript to work:) ...
    (microsoft.public.scripting.jscript)
  • Re: Invoking a base class constructor
    ... >> Constructors don't get inheritted. ... generate B(int, int). ... Inheritance means that the properties of the base ... the compiler does not generate a default constructor. ...
    (comp.lang.cpp)
  • Re: The Language I want
    ... abstract classes are like a contract saying this class cannot be ... class constructors and destructors as well as object ... instantiation), inheritance is useless. ...
    (comp.lang.misc)
  • Copy Constructors/Assignment Operator w/ Inheritance
    ... I'm trying to get inheritance and constructors clear in my head (and ... simply because in the case of D and E they'll call the base class' ... their members "memberwise", and call the base class copy constructor. ...
    (comp.lang.cpp)