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

[Brian Goetz]

So you are proposing E: don’t allow it for lambdas either?

> On Jul 15, 2017, at 6:19 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> I am not confortable with any solution but D, lambdas are just anonymous methods.
> 
> With lambda leftover, we are bridging the gap between methods and lambdas by saying that lambdas have the same scope rules as methods, making lambdas less specific in term of feature. 
> 
> So restricting underscore to lambda only goes is the wrong direction, because it artificially re-create a gap between methods and lambdas in term of feature.
> 
> regards,
> Rémi
> 
> 
> On July 14, 2017 4:38:08 PM GMT+02:00, Vicente Romero <vicente.romero at oracle.com> wrote:
> 
> 
> On 07/10/2017 06:47 AM, Tagir Valeev wrote:
>  Hello!
> 
>  I see that A was selected and currenty I support it. Just a short opinion
>  against C for the record. There are many cases when method does not
>  override another one, but has to declare some parameters. Examples:
>  - public static void main: using main(String[] _) would indicate that
>  command line parameters are not used.
>  - name parameter in BootstrapMethodFactory: often it's unnecessary
>  - some annotation-based APIs when method annotation directs a framework to
>  call this method reflectively with specific parameters (but some of them
>  are not used actually)
>  - a lambda with unused parameter which was converted to a method for
>  convenient use as a method reference
> 
>  So covering traditional inheritance, but not covering these cases looks
>  arbitrary indeed.
> 
> right, good point and thanks for the feedback. We preferred to move to a 
> conservative mode and keep this feature small which was the first intention.
> 
> 
>  With best regards,
>  Tagir Valeev.
> 
> Vicente
> 
> 
>  On Sat, Jul 1, 2017 at 12:38 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
>  So, a fair question is whether _ should be supported for methods at all,
>  because (in many cases) method parameters are both declaration and
>  implementation.  This feature started out for lambdas (whose parameters are
>  pure implementation), and then got extended to catch formals (also pure
>  implementation) and method parameters (not pure implementation.)  And once
>  we bring in methods, it raises tooling questions like "what about Javadoc."
>  So maybe the last step was the problem.
> 
>  Here's a menu of defensible options here:
> 
>  A. Don't allow _ for method or constructor parameters.
> 
>  B. Only allow _ for method parameters in *anonymous* classes. This has the
>  advantage that it makes it easier to freely refactor lambdas to/from anon
>  classes.
> 
>  C. The option I proposed the other day -- only allow _ as a method
>  parameter name for concrete class methods that are known to be an @Override
>  of some other method.  This excludes all interface and abstract methods,
>  constructors, and "initial declarations" of methods in base classes.
> 
>  D. Allow it in all methods.
> 
> 
>  Now that this has been pointed out, I'm pretty down on D.  C is
>  defensible, but likely will feel arbitrary.  B does has a nice symmetry to
>  it, but it means it drags tooling support (Javadoc) into the feature.  And
>  A avoids the problem entirely.  (Though, like with LVTI, people will
>  inevitably ask "but what about private methods?  And they'd get the same
>  answer, regarding source compatibility of modifier changes.)
> 
>  Leaning towards A....
> 
> 
>  On 6/25/2017 6:51 AM, Tagir Valeev 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.
> 
> 
> 
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.