JEP 302: Lambda Leftovers

[Remi Forax]

----- Mail original -----
> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> À: "Nicolai Parlog" <nipa at codefx.org>, platform-jep-discuss at openjdk.java.net
> Envoyé: Mercredi 7 Décembre 2016 12:18:30
> Objet: Re: JEP 302: Lambda Leftovers

> 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.
> 

My gut feeling is that AClassNameWithALongName::m is far more common than this::m, so we can restrict the meaning of ::m to become equivalent to AClassNameWithALongName::m and not to this::m.

As you said in another email, we are now in a better position than during the lambda meetings because we have have a corpus of Java 8 Codes to harvest to see how people use method references.

> Maurizio

Rémi