> On Oct 5, 2018, at 4:18 PM, Brian Goetz <brian.go...@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.
