Draft Spec for Second Preview of Flexible Constructor Bodies (JEP 482)
Stephan Herrmann
stephan.herrmann at berlin.de
Tue Jun 11 13:05:00 UTC 2024
Am 07.06.24 um 23:23 schrieb Maurizio Cimadamore:
>
> On 02/06/2024 22:36, Stephan Herrmann wrote:
>> Do you consider the proposed rules too complex to implement cleanly, or too
>> complex to explain to users?
>
> It's a decent rule and explanation of what the compiler does.
>
> The more I play with code like this, the more I find examples where, on a first
> look is not immediately clear which way the compiler should go (it's kind of
> hard to mentally keep track of which classes have members that can be accessed),
> or how they should be translated. It probably doesn't help that the
> implementation seems to be all over the place in this area.
>
> So, my argument is mostly a pedagogical one, e.g. drawing a clear line that is
> less prone to mis-interpretation and might make the code slightly more readable
> and predictable.
>
> Maurizio
Here's a different perspective that could also affect the pedagogical aspect:
I've seen academic approaches that tackle the initialization issue by
discriminating two variants of every reference type T:
* type "raw T" captures instances that are not yet fully initialized
* type "cooked T" is the type of instances with initialization completed
(sorry for overloading 'raw' in this context, I only wish the distinction
raw-parameterized could be retired completely :) ).
So, within a constructor 'this' always has a "raw" type, which implies that the
things you can do with that value are limited. (In a fully elaborated system
this would even allow post-constructor initialization without risk of exposing
uninitialized fields, or select which methods can be safely invoked on a "raw"
this pointer -- not to mention the great benefit for NPE-analysis).
Perhaps some years from now Java will even adopt such type modifiers, but
already for the discussion at hand I'd think that the existence of any
"Outer.this" can be determined purely based on lexical nesting (unless 'static'
is said explicitly), but semantic analysis will know that some of these
references will have a "raw type", imposing the necessary restrictions. Maybe
existence of enclosing instance references is not boolean but three-valued:
absent-raw-cooked.
IOW, I see nothing awkward with enclosing instance references that impose some
restrictions on their usage. OTOH the implementation pattern "this.this$0" does
*not* require "this" to be fully cooked, right?
best,
Stephan
More information about the amber-spec-experts
mailing list