[lambda-leftovers] Underscore parameter for abstract/native methods

[Remi Forax]

Sometimes you have abstract methods with an unused parameter, by example when you re-abstract something or when you use the functional interface conversion.
1/ the second parameter mean noting for the subtype of B:
  class A {
    void m(String s, Object data) { ... }
  } 
  abstract class B extends A {
    abstract void m(String s, Object _);
  }

2/ functional interface conversion, i want to see a lambda with zero parameter as a lambda with one:
  @FunctionalInterface
  interface Listener<T> {
    void listen(T _);

    static <T> Listener<T> of(Runnable runable) {
      return _ -> runnable.run();
    }
  }

  Listener listener = Listener.of(() -> System.out.println("called"));
  JButton button = ...
  button.addActionListener(listener::listen);

in both case, you want to say that every method/lambda that implements that abstract method should not use the unused parameter.

regards,
Rémi

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Tagir Valeev" <amaembo at gmail.com>
> Cc: amber-dev at openjdk.java.net
> Envoyé: Dimanche 25 Juin 2017 13:06:36
> Objet: Re: [lambda-leftovers] Underscore parameter for abstract/native methods

> Good thought!
> 
> Yes, unnamed parameters are entirely an implementation detail.  There’s a
> spectrum from local variables (pure implementation detail) to abstract methods
> (pure interface declaration), with public concrete methods being somewhere in
> the middle.
> 
> Let’s say we drew the line as you suggest — outlaw _ for abstract methods.  As
> you say, these are interface declaration — and an unnamed parameter in an
> interface declaration could easily be confused for “this parameter may not be
> used”, which is probably not what is meant.
> 
> Now, what about default methods?  Really, the same argument applies — this is an
> interface declaration, even though it happens to have a fallback
> implementation.
> 
> OK, what about non private concrete methods?  Here we’re on shaky ground.  On
> the one hand, this is an interface too — on the other hand, it is an
> implementation.  But …. under what conditions would someone want to leave a
> parameter unnamed in a concrete method?  This really only happens when the
> method overrides a declaration from elsewhere.
> 
> So, I think a sensible and consistent way to draw this line for method
> parameters would be:
> - Only allowed in concrete class methods that override a declaration from
> somewhere else.
> 
> 
> 
>> On Jun 25, 2017, at 12:51 PM, Tagir Valeev <amaembo at gmail.com> wrote:
>> 
>> Hello!
>> 
>> Currently in lambda-leftovers underscore is allowed as a parameter name for
>> abstract methods. This looks dubious as normally underscore means that
>> parameter is not used in the corresponding method/lambda/catch body, but
>> there's no actual body and no parameter is actually used anyways (but could
>> be used in abstract method implementations). I think, allowing underscores
>> for interface methods may encorage bad practices of defining interfaces
>> without readable parameter names:
>> 
>> interface X {
>>  void doSomething(int _, long _, String _);
>> }
>> 
>> Should not this be disabled?
>> 
>> It's even worse for native methods, because underscore assumes that
>> parameter is not used, but it does not limit the corresponding native
>> implementation from using it.
>> 
>> With best regards,
> > Tagir Valeev.