JEP 302: Lambda Leftovers

[Maurizio Cimadamore]

On 07/12/16 10:30, Nicolai Parlog wrote:
>   Hi!
>
> Great proposal! Especially the underscore is cool, much better than
> naming those variables "ignored". I wonder whether I should start using
> two underscores now so I can later replace them with a single one. :) I
> guess it will be possible to use "_" for multiple parameters?
Yes
>
> I would like to request a feature regarding method references. I like
> making non-public methods static to convey the fact that they do not
> interact with or even change the state of the object they are called on.
> But this conflicts with the ease of method references:
>
> 	// `isGenderNeutralName` is an instance method
> 	names.filter(this::isGenderNeutralName)
>
> vs
>
> 	// `isGenderNeutralName` is a static method
> 	names.filter(GenderNeutralNameProcessor::isGenderNeutralName)
>
> As a consequence I often go back and make it an instance method to keep
> the reference readable but it hurts because I give up on an immutability
> signal.
>
> It would be awesome if it were possible to reference a static method in
> the same class without repeating the entire class name. Reusing the
> `class` keyword seems like an obvious* choice:
>
> 	// `isGenderNeutralName` is a static method
> 	names.filter(class::isGenderNeutralName)
>
> Using Martijn's shorthand, IANALE (I Am Not A Language Expert) so I have
> no idea whether this is tractable but it would surely be a nice addition.
I see where you are going - a long class name leads to horizontal noise. 
However, I point out that a similar suggestion could apply to your 
instance method reference - this::isGenderNeutralName - so, why should I 
have to say 'this' if there's only one?

So I think what people would really like would be to eliminate the noise 
completely and just say something like this:

	names.filter(::isGenderNeutralName)


But note that this is a harder problem, as now you have a method 
reference expression that can match both static and instance stuff 
(which is already the case for unbound method reference, but in that 
case you can use arity to disambiguate, whereas here you cannot).

This also goes hand in hand with being able to disambiguate method 
reference easily by adding some formal/actual parameter information; if 
your qualifier expression is shorter, you can in principle have more 
ambiguities - so it could help having some syntactic support to be able 
to distinguish between method references with different signature. This 
topic was also discussed during JDK 8 development but it's not an easy 
problem to solve; ideally, you'd like to be able to denote formal 
parameter types in a method reference, as follows:

	names.filter(::isGenderNeutralName(Object))

But if the method is generic, there could be type-variables in the 
signature, and it's not clear how we denote those in the method 
reference expression.

Another alternative would be to use 'actual argument types' - so 
something like:

	names.filter(::isGenderNeutralName(String))


Where we give the compiler an hint that the first formal should be 
compatible with a 'String' type. But this looks against the spirit of 
method references, whose syntax is deliberately decl-site oriented. So, 
as you can see, optimizing for space in this area could make certain 
problem worse and it's not clear what can be done to offset such 
problems. Of course your original proposal of using 'class' to denote 
'this type' doesn't introduce additional problem, but feels like a side 
move to me.

Maurizio
>
>   so long ... Nicolai
>
>
> * I am aware that the obvious idea might be also be a terrible idea.
>
>
>
> On 07.12.2016 00:50, mark.reinhold at oracle.com wrote:
>> New JEP Candidate: http://openjdk.java.net/jeps/302
>>
>> - Mark
>>