Super() constructor must be first. Is it right?

Question

My previous discussion abot the this issue has been removed. I must reconstruct it to be aware of advantages, disadvantages and bypasses over the restriction.
Obvously, the restriction prevents us from writing some perfectly valid code:
class Unsigned7BitOscillatorInputStream extends OscillatorInputStream {
     Unsigned7BitOscillatorInputStream(
          PeriodicSignal signal,
          float amplitude,
          float signalFrequency,
          AudioFormat f,
          long framesLength)
          // call super substituting the audio format
          super(
               signal,
               amplitude,
               signalFrequency,
               new AudioFormat(AudioFormat.Encoding.PCM_UNSIGNED,
                    f.getSampleRate(),
                    8, f.getChannels(),
                    f.getFrameSize(),
                    f.getFrameRate(),
                    false
               framesLength);
     }It is the same if one writes
class Unsigned7BitOscillatorInputStream extends OscillatorInputStream {
     Unsigned7BitOscillatorInputStream(
          PeriodicSignal signal,
          float amplitude,
          float signalFrequency,
          AudioFormat f,
          long framesLength)
          // create audio format for super class, overriding bps
          AudioFormat format = new AudioFormat(
               AudioFormat.Encoding.PCM_UNSIGNED,
               f.getSampleRate(),
               8,
               f.getChannels(),
               f.getFrameSize(),
               f.getFrameRate(),
               false);
          super(signal, amplitude, signalFrequency, format, framesLength);
     }Fortunately, the new AudioFormat obect can be created inline with super call. Nevertheless, actually, anyway, the instantiation of the local object preceeds the super call. So what was the reason to prevent java programmers from writing strightforward code, make them decieving themselves and looking for ugly bypasses? What if some comuptation must be done and some fields initialized before super can be called? What if I want to log the arguments passed before calling the super constructor? I wonder how java designers know in which order the fields must be initialized/accessed. IMO, it is exactly constructor's competence.

Answer 1

Java was specifically constructed with limitations in
mind based on experience with common problem areas.
Notice that I said "specifically".Does it mean they all the OOP practices are the best? Should I use them as a reference? Which kind of errors does it protect me from? I would like to see a document telling that calling super constructor is evil, really. Peahaps the reasons lie not in best OOP practice but rather some technical/historical sad fact. It would be amusing if you are defending somenes mistake. I'm sure is java did not initially had the real type (float point) for the reason of its support complexity, the java bigots today would prove that the real numbers are evil and the requirement to use this type in your program points to a flaw in your design. The paramount evidence on the best programming practices will, of course, be the JLS bible. Like they prove there must not be a Set.get(key) in the set class/interface. They tell me that there must be none need to request an object of the same class ("class" in math terms) equivalent to that one you have put into the set. They tell me that if I need the method, my design is flawed. However, actually, the lack of the method in java.collections is nothing more than their designer's mistake. The most obvious illustration are relational tables in DB: the keys are parts (fields, members) of records (entities, objects) while tables are nothing more than sets of objects. Using maps in this case is inappropriate and inferes redundancy. But that's another story... Though the superfirst requirement also adds the extra complexity and must be thoroghly justified. Any artifical overcomlication/redundancy must have a solid evidence. IMO, the objected limitation looks like a 5th wheel in a java-telega.
I have programmed with gotos many years ago. My experiance proves the Dykstra's (one of the structural programming fathers) thesis stating the "gotos are evil". The gotos break the flow of control making it hard to follow. Therefore, I readitly accept it. I have never seen the thesis, but I'm sure I can find and refer it to you if you like. At the same time, I'm sure there is nothing similiar in OOP domain telling the "deferred" supercons are evil. Otherwise, you would be more specific in references. Suppose, someone confines you into a prison, argumenting this is a "specific tool/limitation" to prevent "some" problems. Will you agree? You will insist on some more serious criminations? Be happy - they tell you - you are allowed to argument against the confinement appealing to our community (the community are the people believing the authority blindly)! No, it is accepted in justice that any limitation of freedom must be justified, not the contrary! This is called a presumption of innocence. I suffer, I break my mind when I know that the following invocations are the same but the second does not work for some queer reason:
          B() {
          super(computePrereq());
     B() {
          r = computePrereq(); // why this is worse than above? Where is the justice?
          super(r);
I think you can find more than a couple of C++
best practices books and articles that will tell
you how C++ constructors should be built.Wow, you refer me to C++ as a citadel for OOP best practices! OK. CPP::STL "package" has the get_by_key method in the Set class/template. Will this fact chagne the mind of java bigots? Obviously not, they immediately refuse your arguments just hearing c++. I can, but just please be more specific. I may to carefully explore a ton of books without finding any sign of super second is evil.
My favorite lang on Wintel platform is Delphi. Many thoughtful people consider it as a Wintel native java. However, there is even no recommendation to use superconstructors first. And the broad experience suggests me that there is nothing harmful in deferring the superconstruction. I do not feel any nasty frustration similar to exploiting gotos. The super destructors must be called last indeed, since they ultimately call the root superclass's (TObject) destructor, which deallocs the mem and the object ceases to exist after the call. But constructors do not alloc any mem for the object fields, they just fill the fields. The order of initialization is absolutely free. The initialization of all the fields may even be made in parallel for performance.
Delphi also has a interface-resolution mechanism. Two interfaces conflict when they specify two aliasing methods. Will you tell that it is a bad design if happens that two interfaces conflict? The Divide&Concure disign rule tells the contrary, it is bad design when you must care about other blocks developing one. It is java which has design flaw - you must care about names of methods in other interfaces. This is the experiance collected from wast SW/HW methodologies I can share with java community.
Show me why I cannot construct a human without
first
producing an ape?
False analogy. I doubt that anyone would ever
construct an inheritence hierarchy like that.I do not belive in God either ;)
The evolution took itself.
Or construct a tree without first
producing a plant? And that would be logically inconsistent. A tree is
a plant. If plant does not exist then a tree can not
either.OK. Which plant should I create before proceeding to construct a tree? Do you understand that the Plant and Tree are the classes while an instance of the Tree just belongs to these classes? The calsses are loaded prior to construction. Now, I'm creating a tree. It is not your matter how the tree is created. You just get a tree and if it is a valid tree; that is, your tree implements all methods of the interface the tree class commits to implement, then it is also a plant. The construction technology is not important. The constructor knows it better when to create a steam and leafs.
Your analogies are a bit absurd. There are other
more relevent ones though...
Employee (parent) -> surpervisor (child).
Based on your argument it is stupid to have a
supervisor who is an employee. Whereas in the world
I live in the vast majority of the time supervisors
are employees. And in the cases where they aren't
(rare contractual situations) then building a
hierarchy that reflects that relationship is a design
flaw which has nothing to do with construction.Where did I argument against this relatioship? Nevertheless, if it bothers you I can tell you my opinion. In the manager-workers pattern, the emploee (also called a manager) is a job, whos duty consists of finding the workers, hand out a job to them and accepting (supervising) the work done. It may also stimulate/motivate the workers, but that is not important. What's more important is that the surpervision is one of manager's duties. Any Manager is a supervisor by definition. Thus, I can explain why Ape and Human are two different classes in the ancestor-descendant relationship, but I cannot explain you manager-supervisor subclassing... I would establish an Employee class implementing its duty interfaces listed. At least, since multiinheritance is not supported in java and you'll have a problem deriving the Emploee from both task initiator and inspector. If you like.
The plant appears
altogether with a tree. Talking in a scientigic
language, being a plant is nothing more than an
attribute of a tree (which cannot appearahead of the
object). They appear simultaneously and are
indistinguishble as a single whole.You said it not me. If you are using attributes and
nothing else to construct inheritence then your
design is flawed.Excuse me for not understanding/appretiating your humor. The "Tree" objects are attributed to "Plants" class. Don't you agree of what?
To put it bluntly, this is you who seem to use inappropriete terminology. In programming, the parent-children relationship is used for tree structures (has-a). Parent may have (or own) a set of children. However, no parent construction precedes the construction of every "child" object. Otherwise, we would get too many parents. While we need descedants. The descedants have attributes of parents but they are not separate objects. Like keyfields in a DB records. All the fields are equal (if we do not toudch the pragmatic level). The ancestor-descendant terminology is adoped in OOP (the talks about inheritance). In java, super/sub-class notation is accustomed. This sharpens my confusion on which "parents" should I create before initializing any new object specific fields.
Looks like a demagogic sentence. Let's think of a
human as a brain-increased ape without tail. Do
again?) or proceeded directly?
Again you are using a very bad example for
inheritence.I fail to see why the natural exapmles of inheritance are somehow "bad". OK, not all apes are brain-low, since humen break this rule.
No, but I can make a soudspeaker without bringingits
"parent" (presumably, a soundsystem) into "a valid
state". I can write a java program withoutbringing
some "abstract" program into a valid state.
Even worse example. A "sound system" is a
collection of other objects.
There is no way that a speaker is ever a child or a
parent of an amplifier.Thereofore, an abstract soundsystem may not have any concrete descendants? A soundsystem consumes a stream of databits or continous electric signal and produces sound waves. A laudspeaker near to me is full of controls - volume, bass, ets.. What is it if not an incarnation of a sound system?
OK, here is another example. A floppy-disk is a disk. Should one produce a disk before making it floppy? Or microwave owen is an owen. How do you think should I create an owen prior to making it a microwave? Or electric field, how do I create a field prior to adding the electric parameters? Or how do I construct a hammer if you require me to precede its construction by construction of abstract instrument? How do I manufacturers produce "parent" computers before attaching "personal" properties to it? I'm sure there are millions of ways to construct a PC but none of them requires producing some "parent".
OK, which chapter of CS tells that "parents" mustbe
created prior to a "children"? Should Intel start
manufacturning their Pentium chips by producing8088
core first? I am beginning to think that you have a substantially
different view than most people about what
inheritence means.
I find it hard to believe that anyone, in any
situation, would ever attempt to create an
inheritence tree using 8080 as the parent and a
pentium as the child. This is a historical
relationship not a child parent one.The Pentioum extends functionality of 8088 (both HW and SW). Engeneers started more and more features at the core. Finally they got a huge monster. It still starts as 8088. A program can call for extended capabilities if it knows about them. The old programs work on Pentium using its 8088 inherited interface.
What do you mean telling "parent in valid
state"? In construction, only ONE object isproduced,
which complies to its ancestor interface.
Constructors just aid the process. May be youwanted
to tell there is no analogy between OOP and the
nature?A tree is a plant. It is nonsense to suggest that a
tree can exist before plant exists.As I have told, I have never suggested for such a nonsense. The Plant class exits long before you create an instance of a tree.
That has nothing to do with the relationship between
an acorn and an oak however. Nor does the fact that
an oak produces acorns mean that there is a child
parent relationship in terms of OO in there.I have never told that the seeds are plants. Moreover, I do not see any relation here with your proir argument that the creation of instance of an oak must be preceeded by the creation of instantance of some abstract plant (belonging to a Plant class) and the tree instance constructor then must decorate the the basic structure of that plant instance.
Please refer me to a book telling that fields of superclass must be initialized prior to (not after and not concurrently) with the new fields exposed by a subclass.