> On Jul 1, 2021, at 5:48 AM, Brian Goetz <brian.go...@oracle.com> wrote:
>
>
>>
>> Which reminds me: I think we should
>> allow calls to methods on `this` inside a
>> constructor. (Do we?) A clean way to
>> statically exclude incomplete values of `this`
>> would be to outlaw such self-calls until all
>> final fields are definitely assigned. The
>> current language (for identity classes)
>> computes this point (of complete field
>> assignment) in order to enforce the rule
>> that the constructor cannot return until
>> all final fields have been definitely assigned.
>
> FYI: A recent paper on the self-use-from-constructor problem:
> https://dl.acm.org/doi/10.1145/3428243
>
>
Nice; it supports virtual calls in a constructor.
To me that seems a good stretch goal.
A simpler rule would define an “all initialized”
point in the constructor (no DU states, basically)
and open the floodgates there. A more complicated
set of rules could allow earlier access to partially
DU objects, as a compatible extension. In terms
of the paper, the initial conservative approach
does not allow (or perhaps warns on) any typestate
that has a remaining DU in it, while an extended
approach would classify accesses according
to which DU’s they might be compatible with.
An example of the difference would be:
primitive class Complex {
float re, im, abs, arg;
Complex(float re, float im) {
this.re = re;
this.im = im;
if (CONSERVATIVE_AND_SIMPLE) {
// we can easily do this today
this.abs = Complex.computeAbs(re, im);
this.arg = Complex.computeArg(re, im);
} else {
// later, enhanced analysis can allow this.m()
this.abs = this.computeAbs();
this.arg = this.computeArg();
}
}
}
Other observations:
The paper seems to formalize and extend the
DA/DU rules of Java 1.1 (which I am fond of),
under the term “local reasoning about initialization”.
The distinction between objects that are “hot” (old)
and “warm” (under construction) objects seems to
align with some of our discussions about confinement
of “larval” objects before they promote to “adult”.
