What I then wonder is, why is it allowed to call virtual / abstract methods from a constructor (directly or indirectly) ? If you define a constructor as the method to initialize the object so it can be used by its instantiator, it's obvious that calling a hierarchy of methods from the constructor is not a wise thing to do, simply because the constructor is there to initialize an initial state.
Another POV on the matter: It is perhaps also a matter of perception where the 'base class(es)' live from the POV of the derived class: 1) If you see a base class as part of the derived class (and from a POV of a class outside the derived class it is), it must be logical that a part of the derived class (which originally belonged to the base class) can call code in the derived class, in other words: the base class' constructor is mapped into the constructor code of the derived class. 2) If you see a base class as a separate unit which has a child class connected to it, it is logical that the constructor in the child class calls the constructor in the parent class, and the constructor in the parent class is calling code in its own unit, the base class. I think C++ sees it as 2), java and C# see it as 1). FB > Essentially, boiled down, the debate ran something like this: > > Stroustrup commented, in one of his many tirades against > java, that he truly disliked the behavior Java offers, not > because of any efficiency concern, but that it allowed > precisely the hole that you guys have just discovered--a > virtually-dispatched method call may invoke methods or > reference fields on part of an object that's not yet been > initialized. He felt this was a huge violation of > consistency, and so wrote C++ to incrementally initialize its > vtable (and virtual method dispatch > displacements) accordingly. > > Gosling, on the other hand, felt that C++'s approach to > virtual method dispatch was inconsistent--that at any given > point in the object's lifetime, the dispatch resolution for a > virtual method should always be the same, regardless of > whether you're in a constructor or not. Again, not really > much to do with efficiency as it was with language purity. > (Remember, the compiler could, within a constructor, emit an > "invokespecial"--the JVM equivalent to a "call"--instead of a > "invokevirtual"--the JVM equivalent to "calli"--for any > method call on this class while called from within a > constructor body. "Invokespecial" (and its CLI equivalents) > can effectively bypass virtual method dispatch, so it's not > impossible to do if they wanted to.) > > It's really just a question of which semantics you prefer. > Stroustrup felt one way, Gosling (and Haljsberg) felt > differently. Don't like it, write your own C#. :-) > > Ted Neward > Author, Instructor, Presenter: Java and .NET > http://www.neward.net/ted/weblog http://www.javageeks.com > http://www.clrgeeks.com