Responding to Finotti...
>>Hopefully invoking another object's operation in the constructor was
>>done for the sake of simplifying the example and you wouldn't do that
>>sort of thing in practice. B-)
> what's wrong with that?
It depends upon the language, but generally constructors are the most
fragile of methods because the compiler/interpreter is doing
housekeeping that is invisible. For example, the constructor code may
require different privileges than the rest of the application so the
invoked method might introduce an error that goes undetected because it
was running at the wrong privilege level. A less extreme example is
reentrancy. If the called method also instantiates an object the
constructor code may be called recursively and it may not be reentrant.
A variation is that the constructor may optimize by invoking different
version of 'new' depending upon the circumstances and there may be some
interaction with the 'new' invoked by the called method.
One also has a problem determining if they actually worked in most
languages and, if not, what actually went wrong. For example, there is
usually no guarantee that an error handler around the constructor will
be activated if something goes wrong because the constructor code itself
may capture the error transparently.
While such problems are very rare and one can debate whether they are
features or bugs, they also tend to be subtle, non-portable, and
intermittent. So the general rule is: Don't Go There and keep
constructors as simple as possible.
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
Pathfinder Solutions -- We Make UML Work