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

[Remi Forax]

----- Mail original -----
> De: "Remi Forax" <forax at univ-mlv.fr>
> À: "Reinier Zwitserloot" <reinier at zwitserloot.com>
> Cc: "amber-dev" <amber-dev at openjdk.java.net>
> Envoyé: Mercredi 8 Janvier 2020 16:41:37
> Objet: Re: methods-in-methods, can they be static? Should they be externally accessible?

> ----- Mail original -----
>> De: "Reinier Zwitserloot" <reinier at zwitserloot.com>
>> À: "amber-dev" <amber-dev at openjdk.java.net>
>> Envoyé: Mercredi 8 Janvier 2020 15:41:38
>> Objet: methods-in-methods, can they be static? Should they be externally
>> accessible?
> 
>> In regards to:
>> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-January/001904.html
>> ('Towards Cleaner Nesting' - 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.
>> 
>> 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,
> the JLS uses local class for a class inside a method, so a method inside a
> method is a local method.
> 
>> 
>> 2. Is it too early to talk about the semantics of methods in methods? Just
>> in case I misinterpreted the term 'local method' (see #1), I'm going to use
>> the term 'inner method' for any method whose immediate enclosing instance
>> is itself a method.
>> 
>> 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?
> 
> a local method is like a named lambda, the best should be that everything you
> can do with a lambda, you can do it with a local class, retrofittingly seing a
> lambda has a nameless local method.
> 
> a static local method means you are independent of any implicit instances, local
> variables and type parameters, you can see it as a way to clean the scope (it's
> not fully true because you can still access to all static thingy in the scope).
> 
>> 
>> 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.
>> 
>> Before we get bogged down in syntax debates, is this use case (unit tests)
>> worthwhile enough to try to find a way?
> 
> You can not write a unit tests for a lambda.
> So you can not write a unit test for a local method.
> 
> That said, i think we will have to revisit the operator :: and give a meaning to
> ::foo, something we have chosen not to do when designing lambdas.
> The other solution is to have a way to talk about the context of a method but it
> seems a weird concept.
> 
> There are other things to discuss
> - the fact that you may be able to omit the return type the same way a lambda
> omit the return type
>  (with the problem of recursive local methods)
> - the arrow syntax, should the arrow syntax only available to lambdas or
> available to any methods.

and i've forgotten
  - the scope of the local metho parameters, currently you can not have a lambda parameter with the same name
    as local variable. So either we remove this restriction or a local method parameter can not hide
    a local variable.

> 
>> 
>>  --Reinier Zwitserloot
> 

Rémi