JEP 302: Lambda Leftovers

[Nicolai Parlog]

 Hi Maurizio,

thank you for considering this, I appreciate it!

I can not really speak to the problems you listed but, yes,
`::isGenderNeutralName` would of course be nice. On the other hand,
`::isGenderNeutralName(String)`, not so much. To developer Joe (like
myself) putting blank type names in parenthesis looks very strange. Is
there any place in Java, where we do that?

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

If the move forward is not possible, maybe sidewards is not so bad. ;)
Especially since I assume it would be much cheaper than battling the
problems you described.

I like `class` because it is somewhat symmetrical to `this`. It has
the same length and most IDEs use the same color because both are
keywords. They also behave identical when moved into another class,
something that can not be said for the explicit type name.

I also think that this would not preclude `::isGenderNeutralName` in
the future. In that case we're already abandoning
`this::isGenderNeutralName` - leaving `class::isGenderNeutralName`
behind as well does not seem to add much to that.

 so long ... Nicolai



On 07.12.2016 12:18, Maurizio Cimadamore wrote:
> 
> 
> 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
>>> 
> 

-- 

PGP Key:
    http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509

Web:
    http://codefx.org
        a blog about software development
    https://www.sitepoint.com/java
        high-quality Java/JVM content
    http://do-foss.de
        Free and Open Source Software for the City of Dortmund

Twitter:
    https://twitter.com/nipafx