New JEP: Concise Method Bodies

[Dan Smith]

> On Oct 5, 2018, at 4:18 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
>> Can the expression before the :: refer to any method parameters? Of course, it would still expect to pass those parameters into the method, so it's weird to have the same parameter used in both ways, but does it make sense to forbid it?
>> 
> 
> Yes, it makes sense to forbid.  Here's why.  
> 
> The framing of
> 
>     method declaration = behavior literal
> 
> is meant to suggest that the thing on the RHS can be computed ONCE, and that's the "body" of the method.  Therefore, it should only be computable based on what is known in the context of the method (static state for static methods, instance state for instance method.)  It is not merely a shorthand for "take the method ref, turn it into a lambda, and then turn the body of that lambda into a method body."  
> 
> So the thing on the left of the :: must be something that could be, say, the RHS of a field initializer of the appropriate static-ness.  
> 
>> Now we want to introduce a second way to use method references, where that creation/evaluation distinction doesn't exist.
> 
> Same distinction.  You can think of the creation as happening in <init> / <clinit>.  
> 
> Now, a fair question is: when should we evaluate that LHS?  And, is it an error or warning if that LHS is, for example, a nonfinal field?  Good question!  Thanks for bringing this up.  

Yes, glad to see more discussion about this. We talked about it a bit weeks ago, but never got past the "yeah, that's something to think about" stage.

The challenge seems to be finding the right intuition.

1) One interpretation is that the method reference must be a constant—something that can be translated into a JVM linkage instruction without executing any code. (Meanwhile, on the JVM side we've explored some features for declaring concrete methods without a Code attribute.)

2) Another interpretation is Brian's here: the evaluation of a method ref's receiver parameter occurs at class initialization, as if there were an initialization of a static field. This suggests that "linkage" of the method (i.e., computation of a function-like entity representing the body) occurs at class initialization.

3) Or, also suggested above: the evaluation occurs in a constructor, again as if a (in this case, instance) field were initialized with the expression.

4) The evaluation occurs after the constructor has completed, making all fields—including those initialized in the constructor—available.

5) The evaluation occurs just before first method invocation.

6) There is no "linkage" step, the method reference is re-computed on every invocation. Method parameters are in scope. This is the "syntactic sugar" approach, and the one Kevin is taking issue with.

I don't know the right answer, but here are some considerations:

- Another problem with referring to method parameters is that users might expect to exclude a referenced parameter from the parameters passed to the method ref, but the behavior ends up being really ad hoc:

	static void m1(Foo x, Bar y) = x::m; // invoke x.m(x,y) or x.m(y)?
	static void m2(Foo x, Bar y) = y::m; // invoke y.m(x,y) or y.m(x)?
	static void m3(Foo x, Bar y) = f(x,y)::m; // invoke obj.m(x,y) or obj.m()?

- It's not totally clear what we do with 'this'. Kind of seems like it should be treated as the first parameter to be passed, but there are also examples in the JEP that ignore it. And is it allowed to be referenced by the receiver expression?

	void reverse() = Collections::reverse; // invoke Collections.reverse(this)?
	int length(String s) = String::length; // invoke s.length()?
	void altMethod() = ThisClass::method; // invoke this.method()?
	void altMethod2() = this::method; // legal?

- Delegation typically depends on an instance field provided as a constructor parameter, which won't work with (1)-(3), and if the delegation target is meant to be mutable, won't work with (4)-(5) either.

	Foo target;
        int m1() = target::m1;
	int m2() = target::m2;

- Ideally, we would not like to further complicate the class/instance initialization story by adding new execution timing, as in (4) or (5). What Brian's story ((2) and (3)) has going for it is that we already have the infrastructure to describe the timing of these evaluations.

- We can simplify things considerably by prohibiting the expression form—must use Type::name. Effectively, (1) but without support for constant expressions. That means giving up on some use cases.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20181005/0130ff76/attachment.html>