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

[Brian Goetz]

This is a fair suggestion, but we've now stepped way outside of the intended scope of the feature -- it was previously entirely local and gave rise to no compatibility constraints .  I'd sooner say "not for method parameters at all" than flow this sort of constraint to overrides.  

Sent from my iPad

> On Jun 25, 2017, at 3:15 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> 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.