Loosening requirements for super() invocation

Brian Goetz brian.goetz at oracle.com
Wed Jan 25 19:23:10 UTC 2023



>     This brings the spec footprint down considerably, while still
>     eliminating complex/risky workarounds around "super first".
>
>
> Put another way, if a reasonable language change is such a problem for 
> the spec, then that's a problem to solve with the spec, not the language.

Not sure what you mean; the spec is the language, and the language is 
the spec.  Many things that seem simple when describing them in terms of 
"use DA/DU to ..." or "use inference to ..." turn out to be complicated 
to specify -- which means the language changes are more complicated than 
they first seemed.  Gauging the spec impact is how we keep ourselves 
honest about the scope of language changes.

> Now I'm not a spec expert (it seems kind of analogous to being a 
> patent lawyer) but what about this plan:

This is obviously doable, but my recent comments (having looked at what 
the spec impact would be) is saying that this is a more complicated, 
more invasive language feature than the simpler "statements before 
super" feature.  Part of what I'm trying to do here is steer towards 
success by pruning the problem to one that can be achieved without 
spending years immersing yourself in specification.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230125/ddee8b73/attachment.htm>


More information about the amber-dev mailing list