Towards cleaner nesting
Brian Goetz
brian.goetz at oracle.com
Fri Jan 10 03:02:50 UTC 2020
>> Of course, some of these don't make sense, such as "constructors in field initializers", so it's not quite as simple as that, but yes, we should seek to bust the _gratuitous_ restrictions.
> Yeah, thinking a bit more, I guess I'd refine my list like so:
>
> Type declarations:
> - top-level/static classes
> - inner classes*
> - interfaces
> - records
> - enums
> - annotation types
>
> Method declarations:
> - static methods
> - instance/local methods*
> - static initializers
> - instance initializers/constructors*
>
> Variable declarations (leaf nodes, not containers):
> - instance/local variables*
> - static variables
Well, variable declarations are not _quite_ leaf nodes:
int x = switch (foo) {
case 1 -> {
class LocalToSwitch { }
yield new LocalToSwitch();
}
};
So variable initializers can have expressions in them, which can have
statements in them ... which can have local classes. In this way,
static/instance variable initializers are a like static/instance class
initializers.
> And then "anything can be nested inside of anything" has the following exceptions:
>
> - interfaces can't directly contain instance initializers/constructors, instance/local variables, or inner classes (maybe)
In order to have inner classes in an interface, we'd have to have a
non-static modifier, since nested classes in interfaces are allowed now
and are implicitly static.
> - records can't directly contain instance/local variables
>
> - annotation types can't directly contain things prohibited in interfaces, or instance/local methods (maybe)
- currently annos cannot have fields, default methods, or static
methods -- this still seems a reasonable restriction.
> - method declarations of any kind can't directly contain static initializers, instance initializers/constructors, static methods (maybe), or static variables (maybe)
I think static local methods make perfect sense here, because the
meaning of static is being broadened to cover the capture of both
instance context and locals.
> So, not quite "anything goes", but a much shorter and more refined list of prohibitions than we had previously.
Yep.
Your list doesn't treat constructors, either as "what can contain them"
(pretty clear that's classes/records/enums only), or as "what can they
contain" (could a constructor have, for example, a local method or a
local class.)
More information about the amber-spec-experts
mailing list