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

[Vicente Romero]

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