methods-in-methods, can they be static? Should they be externally accessible?

[Brian Goetz]

> My only comment to the majority of that post is to applaud it. From the
> text I gather that the most (to me, anyway) exotic aspect of the plan:
> methods in methods – are not really part of milestone 1.

Correct.  It was important to treat methods uniformly in the nesting 
story, because we _already_ have arbitrary-depth 
class-in-method-in-class-in-method nesting.  Once we have that, the 
scoping for method-in-method falls out naturally, but that is not the #1 
priority here, and there are complexities to local methods that have to 
be worked out (e.g., forward references, mutually recursive local 
methods, etc) before we could support them, though we do want to get there.

> 1.The 'local method branch' that Jesper and Maurizio were talking about
> last Saturday – is that about methods in methods? Is 'local method' the
> terminology for the concept of a method whose immediate enclosing lexical
> context is a method?
Yes.  A variable in a method is a local variable; a class in a method is 
a local class; a method in a method is a local method.
> 2. Is it too early to talk about the semantics of methods in methods?
It mostly is; while we did an exploration on this, and would like to get 
there eventually, this work is mostly on hold while we make progress on 
higher-priority features.

> Syntactically, you can of course put the modifier 'static' on an inner
> method. But what does that mean? Clearly it means you cannot access the
> (non-static) fields of the instance that the enclosing method is in, even
> if your enclosing method is itself non-static. That is obvious. However, if
> I apply Brian's sense of what static means (namely: The lexical context of
> a static anything is solely for namespacing purposes, not for access), it
> would also mean I have no access to any (effectively) final local variables
> declared 'above' me in the enclosing method – something method local
> classes (and, presumably, non-static inner methods) DO get. This also
> conveniently means the inner method can actually be hoisted up to the class
> level by the compiler verbatim; nothing the method could possibly access
> requires synthetic bridgers, the way captured local vars are currently
> transmitted to method local classes via synthetic constructors.
>
> Do I follow Brian's thought process on what 'static' means correctly and,
> thus, will static inner methods be allowed?

Correct.  Static restricts both capture of instance variables and 
effectively final locals from enclosing scopes.  (One can imagine a 
language where the two are separate, and there was another modifier and 
term for "I can capture X but not Y", but that seems more complicated 
than we want.)

> 3. If static inner methods are indeed allowed, any thoughts on allowing
> code that isn't in the outer method to invoke the inner method? The point
> of 'inner methods' is presumably that they are relevant only to the outer
> method and thus this seems to go against the idea, but, for unit tests I
> can foresee some utility in being able to do this. However, because of the
> separated namespace rules (fields and methods each are their own
> namespace), what would the syntax look like? Given:
>
>      class Example {
>          int instanceOuter = 10;
>          void instanceOuter() {
>              static boolean inner() { return true; }
>          }
>      }
>
> How would one invoke the inner method from, say, a unit test class in the
> same package for the Example class? Example.instanceOuter.inner() is
> tricky. Example::instanceOuter.inner() doesn't really feel right, though I
> believe syntactically that can be made to work.

This would not be permitted.  Local methods (like local classes) are a 
technique for structuring the implementation of a method.  (The same is 
true for testing local classes (you can't) or assertions about the 
values of local variables in methods above you on the stack -- they're 
not yours to poke into.

> Before we get bogged down in syntax debates, is this use case (unit tests)
> worthwhile enough to try to find a way?
I would think this is a no; we can't unit-tests local classes (or 
for-loops) either, but we don't get too bothered about that.