🚀 go-pugleaf

Tom.Eugelink@OVSoftware.com writes:

> Right, and that is exactly where IMHO the problem is. It should be
> done at the moment the variable are allocated, because there is no
> reason to do it later. (And doing it later causes problems.)

The object is allocated and zeroed by the "new" VM instruction - then
the constructor is called to initialize. Your solution would mean
either:

1) Class files would have a data segment of "defaults" in addition to
   the already present String heap. Here you would only be able to
   initialize with primitive type constants - very limiting.

or

2) Calling the super constructor would be postponed until directly
   declared fields had been initialized. This has two major drawbacks:

   * The initialization code cannot invoke - directly or indirectly -
     non-static methods or fields in the superclass, since those
     aspects of the object aren't in a "proper" state.

   * If you allow initialization to happen both before and after
     invocation of the superclass' constructor, you start to
     differentiate between initializations that occur outside from
     those declared inside the constructor method.

I vastly prefer the current situation, where the behaviour of
constructors are well-defined and known to the programmers. That the
programmer should avoid invoking non-final/private methods in a
contructor can be thought of as a programming caveat.