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

[forax at univ-mlv.fr]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: amber-dev at openjdk.java.net, "Vicente Romero" <vicente.romero at oracle.com>,
> "Tagir Valeev" <amaembo at gmail.com>
> Envoyé: Samedi 15 Juillet 2017 19:11:09
> Objet: Re: [lambda-leftovers] Underscore parameter for abstract/native methods

> So you are proposing E: don’t allow it for lambdas either?
no, D, allow it for lambdas and methods, 
so i will be able to refactor a lambda to an inner class or vice-versa without much trouble. 

Rémi 

>> On Jul 15, 2017, at 6:19 AM, Remi Forax < [ mailto:forax at univ-mlv.fr |
>> 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 < [
>> mailto:vicente.romero at oracle.com | 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 < [ mailto:brian.goetz at oracle.com |
>>>> 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.