🚀 go-pugleaf

Hm hm. Now that is starting to make sense. I totally agree with 1 not
being a fine solution, so we can stike that one. 

The last one, 2b, I do not agree with: I am making a difference in
initialization by placing the initialisation code outside of the
constructor. So then it is defendable to also treat it differently.

2a, however, I agree, is a hassle: it is just as likely to have the
situation reversed (where the child is depending in the parent) as it
is to get my situation... 

However, looking at possible solutions, it appears that "your"
situation is easily solved by placing the parent dependant
initialization code not in the data definition area, but after the
super() call in the constructor. This would ensure proper
initialization of the parent prior to local initialisation

The other way around is not solved as easily, because I cannot place
initialisation code BEFORE the super(). So executing initialisation
statements contained in the data definition area before the
constructor is called, would get you "best of both methods". Basically
this is the same as placing initialization code before the super(),
and letting the programmer decide what initialzation code is parent
dependant. (Oh oh, treading on eggs here ;-)

Both, or even all, methods of initialization are well-defined (as long
as someone took some time to think about it ;-), and whatever falls
outside of this method could be considered a "programming caveat". So
because this one approach was chosen, does not mean it is better by
default, it should be better for a reason... (And I hate people who
end an agrument with "this is what the standard says" ;-)

Tom




On 22 Jul 1999 10:09:31 +0200, Tor Iver Wilhelmsen
<tor.wilhelmsen@sds.no> wrote:
>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.

>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.
>