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